One document matched: draft-kivinen-ipsecme-secure-password-framework-00.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-04'>
<!ENTITY Kuegler PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-kuegler-ipsecme-pace-ikev2-06'>
<!ENTITY Shin PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-shin-augmented-pake-06'>
]>
<rfc category='info' ipr='trust200902'
docName='draft-kivinen-ipsecme-secure-password-framework-00.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>FI</country>
</postal>
<email>kivinen@iki.fi</email>
</address>
</author>
<date month='May' year='2011' />
<area>Security</area>
<workgroup>IP Security Maintenance and Extensions
(ipsecme)</workgroup>
<abstract>
<t>The IPsecME working group was chartered to provide IKEv2 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 of 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 uses different method to negotiate the use of the method
and also uses different payload formats it is very hard to try to
make implementation where multiple of those systems could
co-exists.</t>
<t>This document tries to create generic way for those methods to
negotiate which one is used and provides one new payload which can
be used to transmit method specific data.</t>
</abstract>
</front>
<middle>
<section title='Introduction'>
<t>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 (<xref target='RFC5996'/>)
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.</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 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.</t>
<t>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.</t>
<t>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 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.</t>
<t>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.</t>
<t>Also as the initiator already knows to which peer it is
connecting to it can limit which methods it uses 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 method 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.</t>
<t>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 (<xref
target='I-D.harkins-ipsecme-spsk-auth'/>, <xref
target='I-D.kuegler-ipsecme-pace-ikev2'/>, and <xref
target='I-D.shin-augmented-pake'/>), and those five new payload
types would already be 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 which secure password method is used needs to
happen during the IKE_SA_INIT exchange. The proposed 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
Payload is included then the negotiation of the secure password
methods happens inside those payloads. </t>
<t>As it might be possible that the 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.</t>
<t>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.</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 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 octect of the data, but this is method
specific, and method is free to format the payload data as it
feels like.</t>
<t>The generic secure passwod 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 something 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>But 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 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. </t>
<t>The IKE_AUTH exchange should look bit like EAP, 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.</t>
<t>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.</t>
<t>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.</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 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.
</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 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>
</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:42:02 |