Secure Password Framework for Internet Key Exchange Version 2 (IKEv2)
draft-kivinen-ipsecme-secure-password-framework-03
The information below is for an old version of the document that is already published as an RFC.
| Document | Type | RFC Internet-Draft (individual in sec area) | |
|---|---|---|---|
| Author | Tero Kivinen | ||
| Last updated | 2015-10-14 (Latest revision 2011-10-31) | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Formats | plain text html xml htmlized pdfized bibtex | ||
| Reviews | |||
| Stream | WG state | (None) | |
| Document shepherd | (None) | ||
| IESG | IESG state | RFC 6467 (Informational) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Sean Turner | ||
| IESG note | Tero Kivinen (kivinen@iki.fi) is the document shepherd. | ||
| Send notices to | (None) |
draft-kivinen-ipsecme-secure-password-framework-03
Network Working Group T. Kivinen
Internet-Draft AuthenTec
Intended status: Informational October 31, 2011
Expires: May 3, 2012
Secure Password Framework for IKEv2
draft-kivinen-ipsecme-secure-password-framework-03.txt
Abstract
This document defines a generic way for Internet Key Exchange version
2 (IKEv2) to use any of the symmetric secure password authentication
methods. Multiple methods are already specified in other documents
and this document does not add any new one. This document specifies
a way to agree on which method is to be used in the current
connection. This document also provides a common way to transmit
secure password authentication method specific payloads between
peers.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 May 3, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Kivinen Expires May 3, 2012 [Page 1]
Internet-Draft Secure Password Framework for IKEv2 October 2011
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Method Negotiation . . . . . . . . . . . . . . . . . . . . . . 6
3. Generic Secure Password Method Payload . . . . . . . . . . . . 8
4. IKE_AUTH Exchange . . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Kivinen Expires May 3, 2012 [Page 2]
Internet-Draft Secure Password Framework for IKEv2 October 2011
1. Introduction
The IPsecME working group was chartered to provide IKEv2 ([RFC5996])
a symmetric secure password authentication protocol that supports the
use of low-entropy shared secrets, but is protected against off-line
dictionary attacks without requiring the use of certificates or
Extensible Authentication Protocol (EAP). There are multiple such
methods and the working group was to pick one. Unfortunately the
working group failed to pick one protocol and there are multiple
candidates going forward as separate documents. As each of those
older versions of those documents used a different technique to
negotiate the use of the method and also used different payload
formats it is very hard to try to make an implementation where
multiple of those systems could co-exists.
Current document versions ([I-D.harkins-ipsecme-spsk-auth],
[I-D.kuegler-ipsecme-pace-ikev2], and [I-D.shin-augmented-pake]) use
the method described in this document.
This document describes IKEv2 payload formats that can be used for
multiple secure password methods to negotiate and transmit data so
each different method can easily co-exist in the same implementation.
This document consists of two major parts:
o How to negotiate which secure password method negotiation is used.
o How to transmit secure password method specific data between
peers.
The secure password methods are not usually meant to be used in the
normal end user (remote access VPN) cases. In such cases EAP based
authentication works fine and the asymmetric nature of EAP does not
matter. In such scenarios the authentication is usually backed up
with the back-end AAA servers and other infrastructure. I.e., in
such scenarios neither of the IKEv2 peers really know the secret, as
in one end it is typed in by the user when it is needed, and on the
other end it is authenticated by the back-end AAA server.
The new secure password methods are meant to be used, for example, in
the authentication between two servers or routers. These scenarios
are usually symmetric: both peers know the shared secret, no back-end
authentication servers are involved, and either end can initiate an
IKEv2 connection. Note that such model could also be supported by
EAP when an EAP method that can run in symmetric fashion is in use,
and the EAP method is directly implemented on both peers and no AAA
is in use.
Kivinen Expires May 3, 2012 [Page 3]
Internet-Draft Secure Password Framework for IKEv2 October 2011
In many cases each implementation will use only one of the proposed
secure password authentication methods, but in many cases the
implementations can include support for multiple methods even when
only one of them will be used. For example, general purpose
operating system running IPsec and IKEv2 and supporting secure
password authentication methods to protect services provided by the
system might need to implement support for several methods. It is
then up to the administrator which one is to be used. As the server
might need to connect to multiple other servers, each implementing
different set of methods, it may not be possible to pick one method
that would serve all cases.
The secure password methods mostly keep the existing IKEv2
IKE_SA_INIT exchange and modify the IKE_AUTH authentication step. As
those methods do not want to add new round trips, that means the
negotiation of which of the secure password methods to use needs to
happen during the IKE_SA_INIT. As the identity of the other end is
only provided inside IKE_AUTH, that means that the responder needs to
select the list of supported methods only based on the IP-address of
the initiator. This could lead to problems if only certain methods
would be acceptable for certain identified peers. Fortunately, as
the authentication is done based on the secret shared between both
peers, the shared-secret should be usable in all of the methods, thus
a remote peer usually does not need to restrict selection of the
method based on the initiator's identity but only based on the
supported methods and the administrative policy.
Also, as the initiator already knows which peer it is connecting
with, it can limit which methods it proposes to the other peer. And
as secure password methods are meant to be used in symmetric cases,
both ends should have similar configuration, i.e., they have the same
shared-secret, and most likely also a list of acceptable
authentication methods to be used. This could also be interpreted so
that there is no need to support method negotiation as both ends can
already see this from the configuration. On the other hand, in most
cases either end does not really care which of the method is used,
but is willing to use any secure method other end supports. In such
cases the automatic negotiation provides a way to make the
configuration easy, i.e., no need to pick one method to be used
between the peers.
The reason for using the common IKEv2 payload to transmit secure
password method specific data between peers is that the payload type
field in the IKEv2 is only 8-bit field, and 62.5% of the range is
already reserved (50% to the private use numbers, and 12.5% to the
IKEv1 payload numbers). This leaves 95 usable numbers out of which
16 are already in use. Original proposal proposed to consume five
payload type numbers. Those five new payload types would already be
Kivinen Expires May 3, 2012 [Page 4]
Internet-Draft Secure Password Framework for IKEv2 October 2011
a 31% increase to the number of currently allocated payload types.
Kivinen Expires May 3, 2012 [Page 5]
Internet-Draft Secure Password Framework for IKEv2 October 2011
2. Method Negotiation
Because all of the methods modify the IKE_AUTH exchange, the
negotiation of the secure password method to be used needs to happen
during the IKE_SA_INIT exchange. The secure password negotiation
exchange would be:
Initiator Responder
-------------------------------------------------------------------
HDR(SPIi=xxx, SPIr=0, IKE_SA_INIT,
Flags: Initiator, Message ID=0),
SAi1, KEi, Ni, [N(SECURE_PASSWORD_METHODS)] -->
<-- HDR(SPIi=xxx, SPIr=yyy, IKE_SA_INIT,
Flags: Response, Message ID=0),
SAr1, KEr, Nr, [CERTREQ],
[N(SECURE_PASSWORD_METHODS)]
If the N(SECURE_PASSWORD_METHODS) Notify Payload is missing, then
normal IKEv2 authentication methods are used. If the Notify Payloads
are included, then the negotiation of the secure password methods
happens inside those payloads.
As it might be possible that future secure password methods will
modify the IKE_AUTH payload in more substantial way, it is better
that as an end result of the negotiation we have exactly one secure
password method that will be used. The initiator will know which
methods are usable when talking to that responder, so the initiator
will send a list of acceptable methods in its IKE_SA_INIT request.
The responder will pick exactly one method and put that to its
response.
The secure password methods are identified by the 16-bit IANA
allocated numbers stored in the Notify Payload notification data
field. If a method supports multiple different password
preprocessing methods, each of those may be allocated a separate
number from this space, or the method might do its own negotiation of
the preprocessing method later. As initiator has already selected
the shared secret it will be using, it will also know which
preprocessing might be needed for it so it should propose only those
preprocessing methods suitable for the selected shared secret. This
means that it is recommended to allocate separate IANA numbers for
different preprocessing methods.
The actual Notify Payload will look like this:
Kivinen Expires May 3, 2012 [Page 6]
Internet-Draft Secure Password Framework for IKEv2 October 2011
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Security Parameter Index (SPI) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Notification Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Protocol ID will be zero, and the SPI Size will also be zero,
meaning that the SPI field will be empty. The Notify Message Type
will be TBD.
The Notification Data contains the list of the 16-bit secure password
method numbers:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secure Password Method #1 | Secure Password Method #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secure Password Method #3 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The response Notify Payload contains exactly one 16-bit secure
password method number inside the Notification Data field.
Kivinen Expires May 3, 2012 [Page 7]
Internet-Draft Secure Password Framework for IKEv2 October 2011
3. Generic Secure Password Method Payload
This payload will contain the secure password payload specific data.
The IKE_AUTH exchanges might have a number of these inside, depending
on what is required and specified by the secure password method. As
the secure password method is already selected during IKE_SA_INIT,
there is no need to repeat the information of the selected secure
password method, thus this payload only contains the method-specific
data. As some secure password methods require multiple different
payloads, they are assumed to include their method specific payload
type inside the payload, for example inside the first octet of the
data. However, This is method-specific, and a method is free to
format the payload data as it wants.
The generic secure password method payload will look like this:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Secure Password Method Specific Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Payload Type for this payload is TBD, and the name used later in
this document is GSPM Payload.
If the method uses secure password method specific payload sub-types
inside the generic secure password method payload, the format will be
like this:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPMS Subtype | |
+-+-+-+-+-+-+-+-+ +
| |
~ Secure Password Method Specific Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This picture is here only for illustrative purposes, the secure
password method will be defining the exact format of the payload
contents.
Kivinen Expires May 3, 2012 [Page 8]
Internet-Draft Secure Password Framework for IKEv2 October 2011
4. IKE_AUTH Exchange
As the negotiation takes place during IKE_SA_INIT, the secure
password methods may modify the IKE_AUTH exchange if needed. To
enable implementing multiple methods easy, it would be recommended
that IKE_AUTH exchange is not to be modified unnecessarily. Adding
zero, one or multiple Generic Secure Password Method Payloads to each
exchange is needed, as is the modification how the AUTH payload is
calculated, but all other changes should be kept minimal.
The IKE_AUTH exchange should look similar to when EAP is used,
meaning that the first request includes IDi, SAi2, TSi, TSr, and some
number of GSPM payloads. The response should include IDr and again a
number of GSPM payloads. There may be multiple exchanges each
consisting of some number of GSPM payloads, and finally when
authentication is done there should be one final exchange where the
request includes the AUTH payload (along with some number of GSPM
payloads) and the response contains AUTH, SAr2, TSi, TSr and some
number of GSPM payloads. The number of GSPM payloads is up to the
secure password method, but usually will less than 3, but depending
on the method, it might be more.
The AUTH payload calculation should include all the data normally
included in addition to the extra data needed by the secure password
method. The secure password method needs to define how the AUTH
payload is calculated.
As the AUTH payload calculation is changed, the secure payload method
should not use any of the existing authentication method numbers in
the AUTH Payload Auth Method field, but instead use the number
allocated in this document. This number is meant to be used by all
secure password authentication methods.
Kivinen Expires May 3, 2012 [Page 9]
Internet-Draft Secure Password Framework for IKEv2 October 2011
Initiator Responder
-------------------------------------------------------------------
HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH,
Flags: Initiator, Message ID=1),
SK {IDi, [CERTREQ,]
GSPM, [GSPM, ...,]
[IDr,] SAi2,
TSi, TSr} -->
<-- HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags:
Response, Message ID=1),
SK {IDr, [CERT,]
GSPM, [GSPM, ...]}
HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH,
Flags: Initiator, Message ID=2),
SK {GSPM, [GSPM, ...,]} -->
<-- HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags:
Response, Message ID=2),
SK {GSPM, [GSPM, ...]}
...
HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH,
Flags: Initiator, Message ID=x),
SK {[GSPM, ...,], AUTH} -->
<-- HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags:
Response, Message ID=x),
SK {[GSPM, ...,] AUTH, SAr2,
TSi, TSr}
Note that the number of the GSPM payloads and other payloads in each
packet will be defined only by the secure password method
documentation, and pictures in this document are only for
illustrative purposes.
Kivinen Expires May 3, 2012 [Page 10]
Internet-Draft Secure Password Framework for IKEv2 October 2011
5. Security Considerations
As this document does not describe an exact protocol, the security
considerations are not relevant. The secure password method document
using payload types described here needs to describe the security
properties of the protocol it describes.
Kivinen Expires May 3, 2012 [Page 11]
Internet-Draft Secure Password Framework for IKEv2 October 2011
6. IANA Considerations
This allocates one new IKEv2 "Notify Messages Types - Status Types":
TBD SECURE_PASSWORD_METHODS
This allocates one new "IKEv2 Authentication Method" number:
TBD Generic Secure Password Authentication Method
This document also adds one new "IKEv2 Payload Types":
TBD Generic Secure Password Method GSPM
This document creates new IANA registry "IKEv2 Secure Password
Methods":
0 RESERVED
Values 1-1024 are reserved to IANA. Values 1024-65535 are for
private use among mutually consenting parties. Changes and additions
to this registry is by expert review.
Kivinen Expires May 3, 2012 [Page 12]
Internet-Draft Secure Password Framework for IKEv2 October 2011
7. References
7.1. Normative References
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
7.2. Informative References
[I-D.harkins-ipsecme-spsk-auth]
Harkins, D., "Secure PSK Authentication for IKE",
draft-harkins-ipsecme-spsk-auth-05 (work in progress),
July 2011.
[I-D.kuegler-ipsecme-pace-ikev2]
Kuegler, D. and Y. Sheffer, "Password Authenticated
Connection Establishment with IKEv2",
draft-kuegler-ipsecme-pace-ikev2-08 (work in progress),
September 2011.
[I-D.shin-augmented-pake]
Shin, S. and K. Kobara, "Most Efficient Augmented
Password-Only Authentication and Key Exchange for IKEv2",
draft-shin-augmented-pake-08 (work in progress),
July 2011.
Kivinen Expires May 3, 2012 [Page 13]
Internet-Draft Secure Password Framework for IKEv2 October 2011
Author's Address
Tero Kivinen
AuthenTec
Eerikinkatu 28
HELSINKI FI-00180
Finland
Email: kivinen@iki.fi
Kivinen Expires May 3, 2012 [Page 14]