| Network Working Group | T. Kivinen |
| Internet-Draft | AuthenTec |
| Intended status: Informational | August 24, 2011 |
| Expires: February 25, 2012 |
Secure Password Framework for IKEv2
draft-kivinen-ipsecme-secure-password-framework-02.txt
This document creates a generic way for Internet Key Exchange (IKEv2) to use any of the symmetric secure password authentication methods. There are multiple methods already specified in other documents and this document does not add new one. This document specifies a way to agree on which method is to be used in current connection. This document also provides a common way to transmit secure password authentication method specific payloads between peers.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on February 25, 2012.
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
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 Simplified BSD License.
The IPsecME working group was chartered to provide IKEv2 ([RFC5996]) a symmetric secure password authentication protocol that supports using of low-entropy shared secrets, but which is protected against off-line dictionary attacks without requiring the use of certificates or Extensible Authentication Protocol (EAP). There are multiple of such methods and working group was supposed to pick one. Unfortunately the working group failed to get pick one protocol and there are multiple candidates going forward as separate documents. As each 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 implementation where multiple of those systems could co-exists.
This document describes a payload formats for IKEv2 which can be used for multiple secure password methods to do negotiation and transmit data so each different method can easily co-exists in the same implementation.
This document consists of two major parts:
The secure password methods are not usually meant to be used in the normal end user (remote access VPN) cases. In such cases the EAP based authentication works fine and the asymmetric nature of the 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 IKEv2 peers really knows the secret, 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 in cases where such back-end AAA-infrastructure does not exists. An example of such case could be 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.
In many cases each implementation will only 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 of the different methods, and it is going to be up to the administrator which one of them are going to be used. As the server might need to connect to multiple other servers, each implementing different set of methods, there might not be possible to pick one method that would be used in all cases.
The secure password methods mostly keeps 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 the IKE_AUTH that means that the responder end needs to select the list of supported methods only based on the IP-address of the initiator. This could lead in to the 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, that shared-secret should be usable in all of the methods, thus remote peer usually does not need to restrict selection of the method based on the initiators identity only based on the supported methods and administrative policy.
Also as the initiator already knows to which peer it is connecting to it can limit which methods it proposes for the other peer. And as secure password methods are meant to be used in the symmetric cases, both end should have similar configuration, i.e., they have same shared-secret, and most likely both also have list of acceptable (or exactly one acceptable) authentication methods to be used. This could also be interpreted that there is no need to support method negotiation as both ends can already see this from configuration. On the other hand in most cases either end does not really care which of the method is used, they are 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 the common IKEv2 payload to be used 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, where 16 is already in use. The current secure password authentication methods already propose to consume five payload type numbers. This 6% of the unallocated number space is not that big on itself, but nothing says there will be only the current three protocols ([I-D.harkins-ipsecme-spsk-auth], [I-D.kuegler-ipsecme-pace-ikev2], and [I-D.shin-augmented-pake]), and those five new payload types would already be 31% increase to the number of currently allocated payload types.
Because all of the methods modify the IKE_AUTH exchange, the negotiation of which secure password method is 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 method will modify the IKE_AUTH payload in more substantial way, it is better that as a end result of the negotiation we have exactly one secure password method which will be used. The initiator will know which methods are usable for him when talking to that responder, so initiator will send 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 to the Notify Payload notification data field. If 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 kind of preprocessing might be needed for it, so it should propose only those preprocessing methods suitable for the selected shared secret. This means that allocating multiple IANA numbers for one secure password method one for each preprocessing method is recommended.
The actual Notify 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
This payload will contain the secure password payload specific data. The IKE_AUTH exchanges might have multiple of these inside, depending what is required and specified by the secure password method selected. As the secure password method is already selected during the IKE_SA_INIT, there is no need to repeat the information of the selected secure password method anymore, thus this payload only contains the method specific data. As some secure password methods do 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, but this is method specific, and method is free to format the payload data as it feels like.
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 something 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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
But this picture is here only for illustrative purposes, the secure password method will be defining the exact format of the payload contents.
As the negotiation happens during the IKE_SA_INIT the secure password methods may modify the IKE_AUTH exchange if needed. To make implementing multiple methods easy it would be recommended that the 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 bit like when EAP is used, meaning that the first request includes IDi, SAi2, TSi, TSr, and some number of GSPM payloads. The response to that should include IDr and again some 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 it might be more depending on the method.
The AUTH payload calculation should include all the same data that is 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 methods 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.
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.
As this document does not describe exact protocol the security considerations are not really relevant. The secure password method document using payload types described here needs to describe the security properties of the protocol it describes.
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.
| [RFC5996] | Kaufman, C., Hoffman, P., Nir, Y. and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. |
| [I-D.harkins-ipsecme-spsk-auth] | Harkins, D, "Secure PSK Authentication for IKE", Internet-Draft draft-harkins-ipsecme-spsk-auth-04, April 2011. |
| [I-D.kuegler-ipsecme-pace-ikev2] | Kuegler, D and Y Sheffer, "Password Authenticated Connection Establishment with IKEv2", Internet-Draft draft-kuegler-ipsecme-pace-ikev2-06, March 2011. |
| [I-D.shin-augmented-pake] | Shin, S and K Kobara, "Most Efficient Augmented Password-Only Authentication and Key Exchange for IKEv2", Internet-Draft draft-shin-augmented-pake-08, July 2011. |