One document matched: draft-kivinen-ipsecme-secure-password-framework-03.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc5996 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5996.xml'>
<!ENTITY Harkins PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-harkins-ipsecme-spsk-auth-05'>
<!ENTITY Kuegler PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-kuegler-ipsecme-pace-ikev2-08'>
<!ENTITY Shin PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-shin-augmented-pake-08'>
]>
<rfc category='info' ipr='trust200902'
docName='draft-kivinen-ipsecme-secure-password-framework-03.txt'>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc='yes' ?>
<?rfc symrefs='yes' ?>
<?rfc sortrefs='yes'?>
<?rfc iprnotified='no' ?>
<?rfc strict='yes' ?>
<front>
<title>Secure Password Framework for IKEv2</title>
<author initials='T.' surname='Kivinen' fullname='Tero Kivinen'>
<organization>AuthenTec</organization>
<address>
<postal>
<street>Eerikinkatu 28</street>
<code>FI-00180</code>
<city>HELSINKI</city>
<country>Finland</country>
</postal>
<email>kivinen@iki.fi</email>
</address>
</author>
<date month='October' year='2011' />
<area>Security</area>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title='Introduction'>
<t>The IPsecME working group was chartered to provide IKEv2 (<xref
target='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.</t>
<t>Current document versions (<xref
target='I-D.harkins-ipsecme-spsk-auth'/>, <xref
target='I-D.kuegler-ipsecme-pace-ikev2'/>, and <xref
target='I-D.shin-augmented-pake'/>) use the method described in
this document.</t>
<t>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.</t>
<t>This document consists of two major parts:
<list style='symbols'>
<t>How to negotiate which secure password method negotiation is
used.</t>
<t>How to transmit secure password method specific data between
peers.</t>
</list></t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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 a 31% increase to the number of currently
allocated payload types.</t>
<!--
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in <xref
target='RFC2119'/>.</t>
-->
</section>
<section title='Method Negotiation'>
<t>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:</t>
<figure><artwork><![CDATA[
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)]
]]></artwork></figure>
<t>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. </t>
<t>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.</t>
<t>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.</t>
<t>The actual Notify Payload will look like this:</t>
<figure><artwork><![CDATA[
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t>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.</t>
<t>The Notification Data contains the list of the 16-bit secure
password method numbers:</t>
<figure><artwork><![CDATA[
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 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t>The response Notify Payload contains exactly one 16-bit secure
password method number inside the Notification Data field.</t>
</section> <!-- Method Negotiation -->
<section title='Generic Secure Password Method Payload'>
<t>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.</t>
<t>The generic secure password method payload will look like
this:</t>
<figure><artwork><![CDATA[
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t>The Payload Type for this payload is TBD, and the name used
later in this document is GSPM Payload.</t>
<t>If the method uses secure password method specific payload
sub-types inside the generic secure password method payload, the
format will be like this:</t>
<figure><artwork><![CDATA[
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t>This picture is here only for illustrative purposes, the
secure password method will be defining the exact format of the
payload contents.</t>
</section> <!-- Generic Secure Password Method Payload -->
<section title='IKE_AUTH Exchange'>
<t>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. </t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<figure><artwork><![CDATA[
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}
]]></artwork></figure>
<t>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.</t>
</section>
<section title='Security Considerations'>
<t>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.
</t>
</section>
<section title='IANA Considerations'>
<t>This allocates one new IKEv2 "Notify Messages Types - Status
Types":</t>
<figure><artwork><![CDATA[
TBD SECURE_PASSWORD_METHODS
]]></artwork></figure>
<t>This allocates one new "IKEv2 Authentication Method"
number:</t>
<figure><artwork><![CDATA[
TBD Generic Secure Password Authentication Method
]]></artwork></figure>
<t>This document also adds one new "IKEv2 Payload Types":</t>
<figure><artwork><![CDATA[
TBD Generic Secure Password Method GSPM
]]></artwork></figure>
<t>This document creates new IANA registry "IKEv2 Secure Password
Methods":</t>
<figure><artwork><![CDATA[
0 RESERVED
]]></artwork></figure>
<t>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.</t>
</section>
</middle>
<back>
<references title="Normative References">
<!-- &rfc2119; -->
&rfc5996;
</references>
<references title='Informative References'>
&Harkins;
&Kuegler;
&Shin;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:40:46 |