Network Working Group K. Chowdhury
Internet-Draft T. Mortsolf
Intended status: Standards Track Starent Networks
Expires: August 29, 2007 February 25, 2007
Additional Authentication Exchanges in the Internet Key Exchange (IKEv2)
Protocol
draft-chowdhury-ikev2-additional-auth-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 29, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Chowdhury & Mortsolf Expires August 29, 2007 [Page 1]
Internet-Draft February 2007
Abstract
The Internet Key Exchange (IKEv2) protocol defines a way to establish
IPsec security association between two end points. Normally the
protocol requires a single authentication step to complete the
exchange and establish IPsec security association between the end
points. However, there are situations were more than one
authentication exchange is required potentially with different
authenticating domains. It is also possible that multiple
authentication steps are performed to authenticate the endpoints for
different services with different traffic selectors. This document
proposes an extension to IKEv2 protocol to achieve this goal with a
single IKE SA.
Table of Contents
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Illustration of the Scenario . . . . . . . . . . . . . . . . . 5
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 7
5. Payload Formats for Additional Auth . . . . . . . . . . . . . 9
5.1. ADDITIONAL_AUTH_SUPPORTED notify payload . . . . . . . . . 9
5.2. ADDITIONAL_AUTH notify payload . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
9. Normative References . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Chowdhury & Mortsolf Expires August 29, 2007 [Page 2]
Internet-Draft February 2007
1. Introduction and Scope
The IKEv2 protocol [RFC4306] defines a way to establish IPsec
security association between two end points. The IKEv2 protocol
assumes that the IKE_AUTH phase is complete as soon as the
authentication method indicates successful authentication. At the
end of IKE_AUTH phase, the default CHILD SA is established with the
appropriate traffic selectors. However, if there is a requirement
for more than one round of authentication within the same IKE SA, it
won't be possible using the base IKEv2 spec [RFC4306].
IKEv2 Multiple Authentication Exchanges [RFC4739] attempts to address
this scenario by allowing the IKE_AUTH exchange to continue after the
first authentication has successfully completed. This solution makes
use of the notification payload called "ANOTHER_AUTH_FOLLOWS". The
end points continue the IKE_AUTH exchange until the
ANOTHER_AUTH_FOLLOWS notification payload is not sent after an
authentication completion. This solution however falls short when
the additional authentication needs to happen anytime after the first
authentication has finished i.e. after the IKE_AUTH phase is over.
For example, after completion of the IPsec/IKEv2 exchange, the end
user may decide to launch a service that needs separate
authentication and separate CHILD_SA. This additional authentication
may even be done with a separate entity than the one involved with
the first authentication.
In this document we define a solution that will allow scenarios where
additional authentication is required with IKEv2.
Chowdhury & Mortsolf Expires August 29, 2007 [Page 3]
Internet-Draft February 2007
2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Chowdhury & Mortsolf Expires August 29, 2007 [Page 4]
Internet-Draft February 2007
3. Illustration of the Scenario
There may be several reasons for additional authentication with
IKEv2. In this section we describe one such scenario.
+-----------+ +------------+
| VAAA | AAA | HAAA |
| in NAP |--------------| Entity-1 |
+-----------+\ +------------+
| \
| \
AAA | \ AAA +------------+
| \_________| HAAA |
| | Entity-2 |
Host | +------------+
+----------+ +----------+
| | IPsec/IKEv2 | |
|Protected |-------------| Tunnel |
|end point | | end point|
+----------+ +----------+
Illustration of the Scenario
Figure 1. Illustration of the Scenario: Multiple Authenticating
Entity
In the above scenario, the Host is running IKEv2 to connect to the
Tunnel Endpoint in the network to gain access to IP services. The
Host (user) has subscription relationship with two Entities, Entity-1
for IP Service-1 and Entity-2 for IP Service-2. Both the entities
require the Host to authenticate and authorize it for IP services.
The host is connecting to a Tunnel end point provided by an Network
Access Provider (NAP). The NAP has a visited AAA which proxies AAA
transactions between the Tunnel Endpoint (IPsec gateway) and the AAA
servers in Entity-1 and Entity-2. The Tunnel endpoint in the NAP is
configured to support multiple IPsec SAs (CHILD SAs) with a single
IKE SA.
If the Host wants to use IP Service-1, it will indicate that via the
IDr field in IKEv2 and run the authentication method that the
Entity-1 dictates. However, after the Host establishes the IPsec
session with the Tunnel Endpoint, if it desires to use IP Service-2,
Chowdhury & Mortsolf Expires August 29, 2007 [Page 5]
Internet-Draft February 2007
it needs to authenticate with Entity-2. At this point, the Host
cannot just establish a CHILD SA using base IKEv2 [RFC4306] since the
CREATE_CHILD_SA message does not include authentication payload. The
extension defined in Multiple Authentication RFC [RFC4306] is not
useful either since, it does not allow the host to run secondary
authentications after the IKE_AUTH phase is over. It also does not
let the host and the Tunnel Endpoint to establish traffic selectors
for different service (e.g. IP Service-2) that are tied to the
secondary authentication only.
In order for the host to get services offered by both the entities
simultaneouly, the host needs to perform two sets of authentications
with the entities providing services but use the same IKE SA. The
proposed solution in this document allows the host to do this.
Chowdhury & Mortsolf Expires August 29, 2007 [Page 6]
Internet-Draft February 2007
4. Solution Overview
We propose to define two new notification payloads to let the host
perform secondary IKE_AUTH exchanges with the tunnel end point at any
time after the initial IKE_AUTH exchange has completed. The first
notification payload is to convey that the endpoints support
additional authentication. The second notification payload is used
by the host when it initiates the additional authentication anytime
after the initial IKEv2 authentication.
Here is an example call flow using EAP as the authentication method
for both the initial (default) and the secondary authentications:
Chowdhury & Mortsolf Expires August 29, 2007 [Page 7]
Internet-Draft February 2007
Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
N(ADDITIONAL_AUTH_SUPPORTED)
HDR, SK {IDi-1, [CERTREQ,] [IDr-1,]
SAi2, TSi-1, TSr-1, N(ADDITIONAL_AUTH_SUPPORTED)}
-->
<-- HDR, SK {[CERT,] AUTH,
EAP }
HDR, SK {EAP} -->
<-- HDR, SK {EAP (success)}
HDR, SK {AUTH} -->
<-- HDR, SK {AUTH, SAr2, TSi-1, TSr-1 }
.
.
. some time elapses
.
initiate second auth
HDR, SK {IDi-2, [CERTREQ,] [IDr-2,]
SAi2, TSi-2, TSr-2, N(ADDITIONAL_AUTH}
-->
<-- HDR, SK {[CERT,] AUTH,
EAP }
HDR, SK {EAP} -->
<-- HDR, SK {EAP (success)}
HDR, SK {AUTH} -->
<-- HDR, SK {AUTH, SAr2, TSi-2, TSr-2 }
Illustration of the Scenario
Chowdhury & Mortsolf Expires August 29, 2007 [Page 8]
Internet-Draft February 2007
5. Payload Formats for Additional Auth
5.1. ADDITIONAL_AUTH_SUPPORTED notify payload
The ADDITIONAL_AUTH_SUPPORTED notification is included in the
IKE_SA_INIT response and optionally in the first IKE_AUTH request to
indicate that the peer supports this specification. The Notify
Message Type is ADDITIONAL_AUTH_SUPPORTED (IANA: TBD-1). The
Protocol ID and SPI Size fields MUST be set to zero, and there is no
data associated with this Notify type.
5.2. ADDITIONAL_AUTH notify payload
The ADDITIONAL_AUTH notification is included in the IKE_AUTH message
to indicate that the peer (host) wants to perform secondary
authentications. The Notify Message Type is ADDITIONAL_AUTH (IANA:
TBD-2).
Chowdhury & Mortsolf Expires August 29, 2007 [Page 9]
Internet-Draft February 2007
6. IANA Considerations
The following notify message numbers MUST be assigned by IANA:
ADDITIONAL_AUTH_SUPPORTED: TBD-1.
ADDITIONAL_AUTH: TBD-2.
Chowdhury & Mortsolf Expires August 29, 2007 [Page 10]
Internet-Draft February 2007
7. Security Considerations
The additional authentication mechanism proposed in this document
uses the same authentication procedure that is part of the baseline
IKEv2 protocol. Any security considerations that apply to the
IKE_AUTH mechanism, such as predictability of preshared keys, have
identical security consequences when an additional authentication is
performed.
Chowdhury & Mortsolf Expires August 29, 2007 [Page 11]
Internet-Draft February 2007
8. Acknowledgements
TBD.
Chowdhury & Mortsolf Expires August 29, 2007 [Page 12]
Internet-Draft February 2007
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4739] Eronen, P. and J. Korhonen, "Multiple Authentication
Exchanges in the Internet Key Exchange (IKEv2) Protocol",
RFC 4739, November 2006.
Chowdhury & Mortsolf Expires August 29, 2007 [Page 13]
Internet-Draft February 2007
Authors' Addresses
Kuntal Chowdhury
Starent Networks
30 International Place
Tewksbury, MA 01876
US
Phone: +1 214-550-1416
Email: kchowdhury@starentnetworks.com
Tim Mortsolf
Starent Networks
30 International Place
Tewksbury, MA 01876
US
Phone: +1 978-851-1125
Email: tmortsolf@starentnetworks.com
Chowdhury & Mortsolf Expires August 29, 2007 [Page 14]
Internet-Draft February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Chowdhury & Mortsolf Expires August 29, 2007 [Page 15]