restructured file layout
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
This commit is contained in:
Martin Willi
@@ -0,0 +1,283 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
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: [email protected]
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
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
|
||||
[email protected].
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Nir Experimental [Page 5]
|
||||
|
||||
Reference in New Issue
Block a user