Network Working Group T. Kivinen
Internet-Draft AuthenTec
Intended status: Informational July 25, 2011
Expires: January 26, 2012
Secure Password Framework for IKEv2draft-kivinen-ipsecme-secure-password-framework-01.txt
Abstract
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 common
way so those methods can 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.
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 January 26, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Kivinen Expires January 26, 2012 [Page 1]

Internet-Draft Secure Password Framework for IKEv2 July 20111. Introduction
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 different method 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 does not create new protocol or even define a protocol
which could be used to do anything. 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:
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 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
Kivinen Expires January 26, 2012 [Page 3]

Internet-Draft Secure Password Framework for IKEv2 July 2011
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 adminstrator 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 shared 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 adminstrative 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],
Kivinen Expires January 26, 2012 [Page 4]

Internet-Draft Secure Password Framework for IKEv2 July 2011
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.
Kivinen Expires January 26, 2012 [Page 5]

Internet-Draft Secure Password Framework for IKEv2 July 20112. Method Negotiation
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 proposed 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 preprosessing
methods each of those may be allocated a separate number from this
space, or the method might do its own negotiation of the
preprosessing method later. As initiator has already selected the
shared secret it will be using it will also know which kind of
preprossing might be needed for it, so it should propose only those
preprosessing methods suitable for the selected shared secret. This
means that allocating multiple IANA numbers for one secure password
method one for each preprosessing method is recommended.
The actual Notify Payload will look like this:
Kivinen Expires January 26, 2012 [Page 6]

Internet-Draft Secure Password Framework for IKEv2 July 20114. IKE_AUTH Exchange
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 unnecessarely. 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.
Kivinen Expires January 26, 2012 [Page 9]

Internet-Draft Secure Password Framework for IKEv2 July 20115. Security Considerations
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.
Kivinen Expires January 26, 2012 [Page 11]