mirror of
https://github.com/strongswan/strongswan.git
synced 2025-11-03 00:01:15 -05:00
e0fe765152
new configuration structure: peer_cfg: configuration related to a peer (authenitcation, ...= ike_cfg: config to use for IKE setup (proposals) child_Cfg: config for CHILD_SA (proposals, traffic selectors) a peer_cfg has one ike_cfg and multiple child_cfg's stroke now uses fixed count of threads
284 lines
10 KiB
Plaintext
284 lines
10 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group Y. Nir
|
||
Request for Comments: 4478 Check Point
|
||
Category: Experimental April 2006
|
||
|
||
|
||
Repeated Authentication in Internet Key Exchange (IKEv2) Protocol
|
||
|
||
Status of This Memo
|
||
|
||
This memo defines an Experimental Protocol for the Internet
|
||
community. It does not specify an Internet standard of any kind.
|
||
Discussion and suggestions for improvement are requested.
|
||
Distribution of this memo is unlimited.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (C) The Internet Society (2006).
|
||
|
||
Abstract
|
||
|
||
This document extends the Internet Key Exchange (IKEv2) Protocol
|
||
document [IKEv2]. With some IPsec peers, particularly in the remote
|
||
access scenario, it is desirable to repeat the mutual authentication
|
||
periodically. The purpose of this is to limit the time that security
|
||
associations (SAs) can be used by a third party who has gained
|
||
control of the IPsec peer. This document describes a mechanism to
|
||
perform this function.
|
||
|
||
1. Introduction
|
||
|
||
In several cases, such as the remote access scenario, policy dictates
|
||
that the mutual authentication needs to be repeated periodically.
|
||
Repeated authentication can usually be achieved by simply repeating
|
||
the Initial exchange by whichever side has a stricter policy.
|
||
|
||
However, in the remote access scenario it is usually up to a human
|
||
user to supply the authentication credentials, and often Extensible
|
||
Authentication Protocol (EAP) is used for authentication, which makes
|
||
it unreasonable or impossible for the remote access gateway to
|
||
initiate the IKEv2 exchange.
|
||
|
||
This document describes a new notification that the original
|
||
Responder can send to the original Initiator with the number of
|
||
seconds before the authentication needs to be repeated. The
|
||
Initiator SHOULD repeat the Initial exchange before that time is
|
||
expired. If the Initiator fails to do so, the Responder may close
|
||
all Security Associations.
|
||
|
||
|
||
|
||
|
||
Nir Experimental [Page 1]
|
||
|
||
RFC 4478 Repeated Authentication in IKEv2 April 2006
|
||
|
||
|
||
Repeated authentication is not the same as IKE SA rekeying, and need
|
||
not be tied to it. The key words "MUST", "MUST NOT", "SHOULD",
|
||
"SHOULD NOT", and "MAY" in this document are to be interpreted as
|
||
described in [RFC2119].
|
||
|
||
2. Authentication Lifetime
|
||
|
||
The Responder in an IKEv2 negotiation MAY be configured to limit the
|
||
time that an IKE SA and the associated IPsec SAs may be used before
|
||
the peer is required to repeat the authentication, through a new
|
||
Initial Exchange.
|
||
|
||
The Responder MUST send this information to the Initiator in an
|
||
AUTH_LIFETIME notification either in the last message of an IKE_AUTH
|
||
exchange, or in an INFORMATIONAL request, which may be sent at any
|
||
time.
|
||
|
||
When sent as part of the IKE SA setup, the AUTH_LIFETIME notification
|
||
is used as follows:
|
||
|
||
Initiator Responder
|
||
------------------------------- -----------------------------
|
||
HDR, SAi1, KEi, Ni -->
|
||
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
|
||
HDR, SK {IDi, [CERT,] [CERTREQ,]
|
||
[IDr,] AUTH, SAi2, TSi, TSr} -->
|
||
<-- HDR, SK {IDr, [CERT,] AUTH,
|
||
SAr2, TSi, TSr,
|
||
N(AUTH_LIFETIME)}
|
||
|
||
The separate Informational exchange is formed as follows:
|
||
|
||
<-- HDR, SK {N(AUTH_LIFETIME)}
|
||
HDR SK {} -->
|
||
|
||
The AUTH_LIFETIME notification is described in Section 3.
|
||
|
||
The original Responder that sends the AUTH_LIFETIME notification
|
||
SHOULD send a DELETE notification soon after the end of the lifetime
|
||
period, unless the IKE SA is deleted before the lifetime period
|
||
elapses. If the IKE SA is rekeyed, then the time limit applies to
|
||
the new SA.
|
||
|
||
An Initiator that received an AUTH_LIFETIME notification SHOULD
|
||
repeat the Initial exchange within the time indicated in the
|
||
notification. The time is measured from the time that the original
|
||
Initiator receives the notification.
|
||
|
||
|
||
|
||
|
||
Nir Experimental [Page 2]
|
||
|
||
RFC 4478 Repeated Authentication in IKEv2 April 2006
|
||
|
||
|
||
A special case is where the notification is sent in an Informational
|
||
exchange, and the lifetime is zero. In that case, the original
|
||
responder SHOULD allow a reasonable time for the repeated
|
||
authentication to occur.
|
||
|
||
The AUTH_LIFETIME notification MUST be protected and MAY be sent by
|
||
the original Responder at any time. If the policy changes, the
|
||
original Responder MAY send it again in a new Informational.
|
||
|
||
The new Initial exchange is not altered. The initiator SHOULD delete
|
||
the old IKE SA within a reasonable time of the new Auth exchange.
|
||
|
||
3. AUTH_LIFETIME Notification
|
||
|
||
The AUTH_LIFETIME message is a notification payload formatted as
|
||
follows:
|
||
|
||
1 2 3
|
||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
! Next Payload !C! RESERVED ! Payload Length !
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
! Protocol ID ! SPI Size ! Notify Message Type !
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
! Lifetime !
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
|
||
o Payload Length is 12.
|
||
o Protocol ID (1 octet) MUST be 0.
|
||
o SPI size is 0 (SPI is in message header).
|
||
o Notify Message type is 16403 by IANA.
|
||
o Lifetime is the amount of time (in seconds) left before the
|
||
peer should repeat the Initial exchange. A zero value
|
||
signifies that the Initial exchange should begin immediately.
|
||
It is usually not reasonable to set this value to less than 300
|
||
(5 minutes) since that is too cumbersome for a user.
|
||
It is also usually not reasonable to set this value to more
|
||
than 86400 (1 day) as that would negate the security benefit of
|
||
repeating the authentication.
|
||
|
||
4. Interoperability with Non-Supporting IKEv2 Implementations
|
||
|
||
IKEv2 implementations that do not support the AUTH_LIFETIME
|
||
notification will ignore it and will not repeat the authentication.
|
||
In that case the original Responder will send a Delete notification
|
||
for the IKE SA in an Informational exchange. Such implementations
|
||
may be configured manually to repeat the authentication periodically.
|
||
|
||
|
||
|
||
|
||
Nir Experimental [Page 3]
|
||
|
||
RFC 4478 Repeated Authentication in IKEv2 April 2006
|
||
|
||
|
||
Non-supporting Responders are not a problem because they will simply
|
||
not send these notifications. In that case, there is no requirement
|
||
that the original Initiator re-authenticate.
|
||
|
||
5. Security Considerations
|
||
|
||
The AUTH_LIFETIME notification sent by the Responder does not
|
||
override any security policy on the Initiator. In particular, the
|
||
Initiator may have a different policy regarding re-authentication,
|
||
requiring more frequent re-authentication. Such an Initiator can
|
||
repeat the authentication earlier then is required by the
|
||
notification.
|
||
|
||
An Initiator MAY set reasonable limits on the amount of time in the
|
||
AUTH_LIFETIME notification. For example, an authentication lifetime
|
||
of less than 300 seconds from SA initiation may be considered
|
||
unreasonable.
|
||
|
||
6. IANA Considerations
|
||
|
||
The IANA has assigned a notification payload type for the
|
||
AUTH_LIFETIME notifications from the IKEv2 Notify Message Types
|
||
registry.
|
||
|
||
7. Normative References
|
||
|
||
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
|
||
4306, December 2005.
|
||
|
||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||
|
||
Author's Address
|
||
|
||
Yoav Nir
|
||
Check Point Software Technologies
|
||
|
||
EMail: ynir@checkpoint.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Nir Experimental [Page 4]
|
||
|
||
RFC 4478 Repeated Authentication in IKEv2 April 2006
|
||
|
||
|
||
Full Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (2006).
|
||
|
||
This document is subject to the rights, licenses and restrictions
|
||
contained in BCP 78, and except as set forth therein, the authors
|
||
retain all their rights.
|
||
|
||
This document and the information contained herein are provided on an
|
||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||
|
||
Intellectual Property
|
||
|
||
The IETF takes no position regarding the validity or scope of any
|
||
Intellectual Property Rights or other rights that might be claimed to
|
||
pertain to the implementation or use of the technology described in
|
||
this document or the extent to which any license under such rights
|
||
might or might not be available; nor does it represent that it has
|
||
made any independent effort to identify any such rights. Information
|
||
on the procedures with respect to rights in RFC documents can be
|
||
found in BCP 78 and BCP 79.
|
||
|
||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||
assurances of licenses to be made available, or the result of an
|
||
attempt made to obtain a general license or permission for the use of
|
||
such proprietary rights by implementers or users of this
|
||
specification can be obtained from the IETF on-line IPR repository at
|
||
http://www.ietf.org/ipr.
|
||
|
||
The IETF invites any interested party to bring to its attention any
|
||
copyrights, patents or patent applications, or other proprietary
|
||
rights that may cover technology that may be required to implement
|
||
this standard. Please address the information to the IETF at
|
||
ietf-ipr@ietf.org.
|
||
|
||
Acknowledgement
|
||
|
||
Funding for the RFC Editor function is provided by the IETF
|
||
Administrative Support Activity (IASA).
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Nir Experimental [Page 5]
|
||
|