idnits 2.17.1 draft-kivinen-ipsecme-secure-password-framework-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2011) is 4551 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CERTREQ' is mentioned on line 185, but not defined ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) == Outdated reference: A later version (-08) exists of draft-harkins-ipsecme-spsk-auth-05 == Outdated reference: A later version (-10) exists of draft-kuegler-ipsecme-pace-ikev2-08 == Outdated reference: A later version (-15) exists of draft-shin-augmented-pake-08 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Kivinen 3 Internet-Draft AuthenTec 4 Intended status: Informational October 31, 2011 5 Expires: May 3, 2012 7 Secure Password Framework for IKEv2 8 draft-kivinen-ipsecme-secure-password-framework-03.txt 10 Abstract 12 This document defines a generic way for Internet Key Exchange version 13 2 (IKEv2) to use any of the symmetric secure password authentication 14 methods. Multiple methods are already specified in other documents 15 and this document does not add any new one. This document specifies 16 a way to agree on which method is to be used in the current 17 connection. This document also provides a common way to transmit 18 secure password authentication method specific payloads between 19 peers. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on May 3, 2012. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Method Negotiation . . . . . . . . . . . . . . . . . . . . . . 6 63 3. Generic Secure Password Method Payload . . . . . . . . . . . . 8 64 4. IKE_AUTH Exchange . . . . . . . . . . . . . . . . . . . . . . 9 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 1. Introduction 74 The IPsecME working group was chartered to provide IKEv2 ([RFC5996]) 75 a symmetric secure password authentication protocol that supports the 76 use of low-entropy shared secrets, but is protected against off-line 77 dictionary attacks without requiring the use of certificates or 78 Extensible Authentication Protocol (EAP). There are multiple such 79 methods and the working group was to pick one. Unfortunately the 80 working group failed to pick one protocol and there are multiple 81 candidates going forward as separate documents. As each of those 82 older versions of those documents used a different technique to 83 negotiate the use of the method and also used different payload 84 formats it is very hard to try to make an implementation where 85 multiple of those systems could co-exists. 87 Current document versions ([I-D.harkins-ipsecme-spsk-auth], 88 [I-D.kuegler-ipsecme-pace-ikev2], and [I-D.shin-augmented-pake]) use 89 the method described in this document. 91 This document describes IKEv2 payload formats that can be used for 92 multiple secure password methods to negotiate and transmit data so 93 each different method can easily co-exist in the same implementation. 95 This document consists of two major parts: 97 o How to negotiate which secure password method negotiation is used. 99 o How to transmit secure password method specific data between 100 peers. 102 The secure password methods are not usually meant to be used in the 103 normal end user (remote access VPN) cases. In such cases EAP based 104 authentication works fine and the asymmetric nature of EAP does not 105 matter. In such scenarios the authentication is usually backed up 106 with the back-end AAA servers and other infrastructure. I.e., in 107 such scenarios neither of the IKEv2 peers really know the secret, as 108 in one end it is typed in by the user when it is needed, and on the 109 other end it is authenticated by the back-end AAA server. 111 The new secure password methods are meant to be used, for example, in 112 the authentication between two servers or routers. These scenarios 113 are usually symmetric: both peers know the shared secret, no back-end 114 authentication servers are involved, and either end can initiate an 115 IKEv2 connection. Note that such model could also be supported by 116 EAP when an EAP method that can run in symmetric fashion is in use, 117 and the EAP method is directly implemented on both peers and no AAA 118 is in use. 120 In many cases each implementation will use only one of the proposed 121 secure password authentication methods, but in many cases the 122 implementations can include support for multiple methods even when 123 only one of them will be used. For example, general purpose 124 operating system running IPsec and IKEv2 and supporting secure 125 password authentication methods to protect services provided by the 126 system might need to implement support for several methods. It is 127 then up to the administrator which one is to be used. As the server 128 might need to connect to multiple other servers, each implementing 129 different set of methods, it may not be possible to pick one method 130 that would serve all cases. 132 The secure password methods mostly keep the existing IKEv2 133 IKE_SA_INIT exchange and modify the IKE_AUTH authentication step. As 134 those methods do not want to add new round trips, that means the 135 negotiation of which of the secure password methods to use needs to 136 happen during the IKE_SA_INIT. As the identity of the other end is 137 only provided inside IKE_AUTH, that means that the responder needs to 138 select the list of supported methods only based on the IP-address of 139 the initiator. This could lead to problems if only certain methods 140 would be acceptable for certain identified peers. Fortunately, as 141 the authentication is done based on the secret shared between both 142 peers, the shared-secret should be usable in all of the methods, thus 143 a remote peer usually does not need to restrict selection of the 144 method based on the initiator's identity but only based on the 145 supported methods and the administrative policy. 147 Also, as the initiator already knows which peer it is connecting 148 with, it can limit which methods it proposes to the other peer. And 149 as secure password methods are meant to be used in symmetric cases, 150 both ends should have similar configuration, i.e., they have the same 151 shared-secret, and most likely also a list of acceptable 152 authentication methods to be used. This could also be interpreted so 153 that there is no need to support method negotiation as both ends can 154 already see this from the configuration. On the other hand, in most 155 cases either end does not really care which of the method is used, 156 but is willing to use any secure method other end supports. In such 157 cases the automatic negotiation provides a way to make the 158 configuration easy, i.e., no need to pick one method to be used 159 between the peers. 161 The reason for using the common IKEv2 payload to transmit secure 162 password method specific data between peers is that the payload type 163 field in the IKEv2 is only 8-bit field, and 62.5% of the range is 164 already reserved (50% to the private use numbers, and 12.5% to the 165 IKEv1 payload numbers). This leaves 95 usable numbers out of which 166 16 are already in use. Original proposal proposed to consume five 167 payload type numbers. Those five new payload types would already be 168 a 31% increase to the number of currently allocated payload types. 170 2. Method Negotiation 172 Because all of the methods modify the IKE_AUTH exchange, the 173 negotiation of the secure password method to be used needs to happen 174 during the IKE_SA_INIT exchange. The secure password negotiation 175 exchange would be: 177 Initiator Responder 178 ------------------------------------------------------------------- 179 HDR(SPIi=xxx, SPIr=0, IKE_SA_INIT, 180 Flags: Initiator, Message ID=0), 181 SAi1, KEi, Ni, [N(SECURE_PASSWORD_METHODS)] --> 183 <-- HDR(SPIi=xxx, SPIr=yyy, IKE_SA_INIT, 184 Flags: Response, Message ID=0), 185 SAr1, KEr, Nr, [CERTREQ], 186 [N(SECURE_PASSWORD_METHODS)] 188 If the N(SECURE_PASSWORD_METHODS) Notify Payload is missing, then 189 normal IKEv2 authentication methods are used. If the Notify Payloads 190 are included, then the negotiation of the secure password methods 191 happens inside those payloads. 193 As it might be possible that future secure password methods will 194 modify the IKE_AUTH payload in more substantial way, it is better 195 that as an end result of the negotiation we have exactly one secure 196 password method that will be used. The initiator will know which 197 methods are usable when talking to that responder, so the initiator 198 will send a list of acceptable methods in its IKE_SA_INIT request. 199 The responder will pick exactly one method and put that to its 200 response. 202 The secure password methods are identified by the 16-bit IANA 203 allocated numbers stored in the Notify Payload notification data 204 field. If a method supports multiple different password 205 preprocessing methods, each of those may be allocated a separate 206 number from this space, or the method might do its own negotiation of 207 the preprocessing method later. As initiator has already selected 208 the shared secret it will be using, it will also know which 209 preprocessing might be needed for it so it should propose only those 210 preprocessing methods suitable for the selected shared secret. This 211 means that it is recommended to allocate separate IANA numbers for 212 different preprocessing methods. 214 The actual Notify Payload will look like this: 216 1 2 3 217 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 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Next Payload |C| RESERVED | Payload Length | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Protocol ID | SPI Size | Notify Message Type | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | | 224 ~ Security Parameter Index (SPI) ~ 225 | | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | | 228 ~ Notification Data ~ 229 | | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 The Protocol ID will be zero, and the SPI Size will also be zero, 233 meaning that the SPI field will be empty. The Notify Message Type 234 will be TBD. 236 The Notification Data contains the list of the 16-bit secure password 237 method numbers: 239 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Secure Password Method #1 | Secure Password Method #2 | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Secure Password Method #3 | ... | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 The response Notify Payload contains exactly one 16-bit secure 248 password method number inside the Notification Data field. 250 3. Generic Secure Password Method Payload 252 This payload will contain the secure password payload specific data. 253 The IKE_AUTH exchanges might have a number of these inside, depending 254 on what is required and specified by the secure password method. As 255 the secure password method is already selected during IKE_SA_INIT, 256 there is no need to repeat the information of the selected secure 257 password method, thus this payload only contains the method-specific 258 data. As some secure password methods require multiple different 259 payloads, they are assumed to include their method specific payload 260 type inside the payload, for example inside the first octet of the 261 data. However, This is method-specific, and a method is free to 262 format the payload data as it wants. 264 The generic secure password method payload will look like this: 266 1 2 3 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Next Payload |C| RESERVED | Payload Length | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | | 272 ~ Secure Password Method Specific Data ~ 273 | | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 The Payload Type for this payload is TBD, and the name used later in 277 this document is GSPM Payload. 279 If the method uses secure password method specific payload sub-types 280 inside the generic secure password method payload, the format will be 281 like this: 283 1 2 3 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Next Payload |C| RESERVED | Payload Length | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | SPMS Subtype | | 289 +-+-+-+-+-+-+-+-+ + 290 | | 291 ~ Secure Password Method Specific Data ~ 292 | | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 This picture is here only for illustrative purposes, the secure 296 password method will be defining the exact format of the payload 297 contents. 299 4. IKE_AUTH Exchange 301 As the negotiation takes place during IKE_SA_INIT, the secure 302 password methods may modify the IKE_AUTH exchange if needed. To 303 enable implementing multiple methods easy, it would be recommended 304 that IKE_AUTH exchange is not to be modified unnecessarily. Adding 305 zero, one or multiple Generic Secure Password Method Payloads to each 306 exchange is needed, as is the modification how the AUTH payload is 307 calculated, but all other changes should be kept minimal. 309 The IKE_AUTH exchange should look similar to when EAP is used, 310 meaning that the first request includes IDi, SAi2, TSi, TSr, and some 311 number of GSPM payloads. The response should include IDr and again a 312 number of GSPM payloads. There may be multiple exchanges each 313 consisting of some number of GSPM payloads, and finally when 314 authentication is done there should be one final exchange where the 315 request includes the AUTH payload (along with some number of GSPM 316 payloads) and the response contains AUTH, SAr2, TSi, TSr and some 317 number of GSPM payloads. The number of GSPM payloads is up to the 318 secure password method, but usually will less than 3, but depending 319 on the method, it might be more. 321 The AUTH payload calculation should include all the data normally 322 included in addition to the extra data needed by the secure password 323 method. The secure password method needs to define how the AUTH 324 payload is calculated. 326 As the AUTH payload calculation is changed, the secure payload method 327 should not use any of the existing authentication method numbers in 328 the AUTH Payload Auth Method field, but instead use the number 329 allocated in this document. This number is meant to be used by all 330 secure password authentication methods. 332 Initiator Responder 333 ------------------------------------------------------------------- 334 HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, 335 Flags: Initiator, Message ID=1), 336 SK {IDi, [CERTREQ,] 337 GSPM, [GSPM, ...,] 338 [IDr,] SAi2, 339 TSi, TSr} --> 341 <-- HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags: 342 Response, Message ID=1), 343 SK {IDr, [CERT,] 344 GSPM, [GSPM, ...]} 346 HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, 347 Flags: Initiator, Message ID=2), 348 SK {GSPM, [GSPM, ...,]} --> 350 <-- HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags: 351 Response, Message ID=2), 352 SK {GSPM, [GSPM, ...]} 353 ... 355 HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, 356 Flags: Initiator, Message ID=x), 357 SK {[GSPM, ...,], AUTH} --> 359 <-- HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags: 360 Response, Message ID=x), 361 SK {[GSPM, ...,] AUTH, SAr2, 362 TSi, TSr} 364 Note that the number of the GSPM payloads and other payloads in each 365 packet will be defined only by the secure password method 366 documentation, and pictures in this document are only for 367 illustrative purposes. 369 5. Security Considerations 371 As this document does not describe an exact protocol, the security 372 considerations are not relevant. The secure password method document 373 using payload types described here needs to describe the security 374 properties of the protocol it describes. 376 6. IANA Considerations 378 This allocates one new IKEv2 "Notify Messages Types - Status Types": 380 TBD SECURE_PASSWORD_METHODS 382 This allocates one new "IKEv2 Authentication Method" number: 384 TBD Generic Secure Password Authentication Method 386 This document also adds one new "IKEv2 Payload Types": 388 TBD Generic Secure Password Method GSPM 390 This document creates new IANA registry "IKEv2 Secure Password 391 Methods": 393 0 RESERVED 395 Values 1-1024 are reserved to IANA. Values 1024-65535 are for 396 private use among mutually consenting parties. Changes and additions 397 to this registry is by expert review. 399 7. References 401 7.1. Normative References 403 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 404 "Internet Key Exchange Protocol Version 2 (IKEv2)", 405 RFC 5996, September 2010. 407 7.2. Informative References 409 [I-D.harkins-ipsecme-spsk-auth] 410 Harkins, D., "Secure PSK Authentication for IKE", 411 draft-harkins-ipsecme-spsk-auth-05 (work in progress), 412 July 2011. 414 [I-D.kuegler-ipsecme-pace-ikev2] 415 Kuegler, D. and Y. Sheffer, "Password Authenticated 416 Connection Establishment with IKEv2", 417 draft-kuegler-ipsecme-pace-ikev2-08 (work in progress), 418 September 2011. 420 [I-D.shin-augmented-pake] 421 Shin, S. and K. Kobara, "Most Efficient Augmented 422 Password-Only Authentication and Key Exchange for IKEv2", 423 draft-shin-augmented-pake-08 (work in progress), 424 July 2011. 426 Author's Address 428 Tero Kivinen 429 AuthenTec 430 Eerikinkatu 28 431 HELSINKI FI-00180 432 Finland 434 Email: kivinen@iki.fi