idnits 2.17.1 draft-ietf-hokey-erp-aak-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (March 14, 2011) is 4786 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5296 (Obsoleted by RFC 6696) == Outdated reference: A later version (-14) exists of draft-ietf-dime-local-keytran-08 -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Cao 3 Internet-Draft H. Deng 4 Intended status: Standards Track China Mobile 5 Expires: September 15, 2011 Y. Wang 6 Q. Wu 7 Huawei Technologies Co., Ltd. 8 G. Zorn 9 Network Zen 10 March 14, 2011 12 EAP Re-authentication Protocol Extensions for Authenticated Anticipatory 13 Keying (ERP/AAK) 14 draft-ietf-hokey-erp-aak-04 16 Abstract 18 The Extensible Authentication Protocol (EAP) is a generic framework 19 supporting multiple of authentication methods. 21 The EAP Re-authentication Protocol (ERP) specifies extensions to EAP 22 and the EAP keying hierarchy to support an EAP method-independent 23 protocol for efficient re-authentication between the peer and an EAP 24 re-authentication server through any authenticator. 26 Authenticated Anticipatory Keying (AAK) is a method by which 27 cryptographic keying material may be established prior to handover 28 upon one or more candidate attachment points (CAPs). AAK uses the 29 AAA infrastructure for key transport. 31 This document specifies the extensions necessary to enable AAK 32 support in ERP. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 15, 2011. 50 Copyright Notice 52 Copyright (c) 2011 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 3 70 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 3. ERP/AAK Overview . . . . . . . . . . . . . . . . . . . . . . . 4 72 4. ERP/AAK Key Hierarchy . . . . . . . . . . . . . . . . . . . . 5 73 5. Packet and TLV Extension . . . . . . . . . . . . . . . . . . . 6 74 5.1. EAP-Initiate/Re-auth-Start Packet Extension . . . . . . . 6 75 5.2. EAP-Initiate/Re-auth Packet Extension . . . . . . . . . . 7 76 5.3. EAP-Finish/Re-auth extension . . . . . . . . . . . . . . . 9 77 5.4. TV/TLV and sub-TLV Attributes . . . . . . . . . . . . . . 10 78 6. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 11 79 7. AAA Transport Considerations . . . . . . . . . . . . . . . . . 11 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 82 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 85 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 87 1. Introduction 89 The Extensible Authentication Protocol (EAP) [RFC3748] is a generic 90 framework supporting multiple types of authentication methods. In 91 systems where EAP is used for authentication, it is desirable to not 92 repeat the entire EAP exchange with another authenticator. The EAP 93 Re-authentication Protocol (ERP) [RFC5296] specifies extensions to 94 EAP and the EAP keying hierarchy to support an EAP method-independent 95 protocol for efficient re-authentication between the peer and an EAP 96 re-authentication server through any authenticator. The re- 97 authentication server may be in the home network or in the local 98 network to which the peer is connecting. 100 Authenticated Anticipatory Keying (AAK) [RFC5836] is a method by 101 which cryptographic keying material may be established prior to 102 handover upon one or more candidate attachment points (CAPs). AAK 103 utilizes the AAA infrastructure for key transport. 105 This document specifies the extensions necessary to enable AAK 106 support in ERP. 108 2. Terminology 110 2.1. Standards Language 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 2.2. Acronyms 118 The following acronyms are used in this document; see the references 119 for more details. 121 AAA Authentication, Authorization and Accounting [RFC3588] 123 CAP Candidate Attachment Point [RFC5836] 125 EA Abbreviation for "ERP/AAK"; used in figures 127 MH Mobile Host 129 SAP Serving Attachment Point [RFC5836] 131 3. ERP/AAK Overview 133 ERP/AAK is intended to allow the establishment of cryptographic 134 keying materials on a single Candidate Attachment Points prior to the 135 arrival of the MH at the Candidate Access Network (CAN). The 136 document also specifies a method by which the SAP may send the 137 identities of neighboring attachment points to the peer in the EAP- 138 Initiate/Re-auth-Start message. 140 It is assumed that the peer has previously completed full EAP 141 authentication. Figure 1 shows the general protocol exchange by 142 which the keying material is established on the CAP. This document 143 only discusses the case of distributing the key to a single CAP. 145 +------+ +-----+ +-----+ +-----------+ 146 | Peer | | SAP | | CAP | | EA Server | 147 +--+---+ +--+--+ +--+--+ +-----+-----+ 148 | | | | 149 1. | [EAP-Initiate/ | | | 150 | Re-auth-start | | | 151 | (E-flag) | | | 152 |<---------------| | | 153 | | | | 154 2. | EAP-Initiate/ | | | 155 | Re-auth | | | 156 | (E-flag) | | | 157 |--------------->| | | 158 3. | | AAA(EAP-Initiate/Re-auth(E-flag))| 159 | |--------------------------------->| 160 | | | +---------+---------+ 161 | | | | CA authorized & | 162 4. | | | | authenticated; | 163 | | | | EA keying | 164 | | | | materials derived | 165 | | | +---------+---------+ 166 5. | | | | 167 | | | AAA(pMSK) | 168 | | |<----------------->| 169 | | | | 170 6. | | AAA (EAP-Finish/Re-auth(E-flag)) | 171 | |<---------------------------------| 172 7. | EAP-Finish/ | | | 173 | Re-auth(E-flag)| | | 174 |<---------------| | | 175 | | | | 177 Figure 1: ERP/AAK Operation 179 ERP/AAK re-uses the packet format defined by ERP, but specifies a new 180 flag to differentiate EAP early-authentication from EAP re- 181 authentication. The peer initiates ERP/AAK itself, or does so in 182 response to an EAP-Initiate/Re-Auth-Start message from the SAP. In 183 this document, it is required that the SAP should support ERP/AAK. 184 If either the peer or the SAP does not support ERP/AAK, it should 185 fall back to full EAP authentication. 187 The peer sends an early-authentication request message (EAP-Initiate/ 188 Re-auth with the 'E' flag set) containing the keyName-NAI, the NAS- 189 Identifier, rIK and sequence number. The realm in the keyName-NAI 190 field is used to locate the peer's ERP/AAK server. The NAS- 191 Identifier is used to identify the CAP. The rIK is used to protect 192 the message. The sequence number is used for replay protection. To 193 avoid the same pre-established Master Session Key (pMSK) being 194 derived for multiple CAPs, the sequence number MUST be unique for 195 each CAP. 197 The SAP encapsulates the early-authentication message into a AAA 198 message and sends it to the peer's ERP/AAK server in the realm 199 indicated in the keyName-NAI field. 201 Upon receiving the message, the ERP/AAK server first checks its 202 integrity and freshness, then authenticates and authorizes the CAP 203 presented in the NAS-Identifier TLV(s). After the CAP is 204 authenticated and authorized successfully, the ERP/AAK server derives 205 the pRK and the subsequent pMSK for the CAP. 207 The ERP/AAK server transports the pMSK to the authenticated and 208 authorized CAP(s) via AAA as described in Section 7. 210 Finally, the ERP/AAK server sends the early-authentication finish 211 message (EAP-Finish/Re-auth with E-flag set) containing the 212 determinated CAP to the peer via the SAP. 214 4. ERP/AAK Key Hierarchy 216 As an optimization of ERP, ERP/AAK uses key hierarchy similar to that 217 of ERP. The EMSK is used to derive the ERP/AAK pre-established Root 218 Key (pRK). Similarly, the ERP/AAK pre-established Integrity Key 219 (pIK) and the pre-established Master Session Key (pMSK) are derived 220 from the pRK. The pMSK is established for the CAP(s) when the peer 221 early authenticates to the network. The pIK is established for the 222 peer to re-authenticate the network after handover. The hierarchy 223 relationship is illustrated in Figure 2, below. 225 DSRK EMSK 226 | | 227 +---+---+---+---+ 228 | | | 229 pRK rRK ... 231 Figure 2 233 The EMSK and DSRK both can be used to derive the pRK. In general, 234 the pRK is derived from the EMSK in case of the peer moving in the 235 home AAA realm and derived from the DRSK in case of the peer moving 236 in the visited AAA realm. The DSRK is delivered from the EAP server 237 to the ERP/AAK server as specified in [I-D.ietf-dime-local-keytran]. 238 If the peer has previously authenticated by means of ERP or ERP/AAK, 239 the DSRK SHOULD be directly re-used. 241 pRK 242 | 243 +--------+--------+ 244 | | | 245 pIK pMSK ... 247 Figure 3 249 The pRK is used to derive the pIK and pMSK for the CAP(s). Different 250 sequence numbers for each CAP MUST be used to derive the unique 251 pMSK(s). 253 5. Packet and TLV Extension 255 This section describes the packet and TLV extensions for the ERP/AAK 256 exchange. 258 5.1. EAP-Initiate/Re-auth-Start Packet Extension 260 Figure 4 shows the changed parameters contained in the EAP-Initiate/ 261 Re-auth-Start packet defined in RFC 5296 [RFC5296]. 263 0 1 2 3 264 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 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Code | Identifier | Length | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Type |E| Reserved | 1 or more TVs or TLVs ~ 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 Figure 4 273 Flags 275 'E' - The E flag is used to indicate early-authentication. 277 Reserved: MUST be set to 0. 279 TVs and TLVs 281 NAS-Identifier: As defined in [RFC5296], it is carried in a TLV 282 payload. It is used by the SAP to advertise the identifier(s) of 283 CAP(s) to the peer. One or more NAS-Identifier TLVs MAY be included 284 in the EAP-Initiate/Re-auth-Start packet if the SAP has performed CAP 285 discovery. 287 If the EAP-Initiate/Re-auth-Start packet is not supported by the 288 peer, it is discarded silently. 290 5.2. EAP-Initiate/Re-auth Packet Extension 292 Figure 5 illustrates the changed parameters contained in the EAP- 293 Initiate/Re-auth packet defined in RFC 5296 [RFC5296]. 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Code | Identifier | Length | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Type |R|x|L|E|Resved | SEQ | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | 1 or more TVs or TLVs ~ 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Cryptosuite | Authentication Tag ~ 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 Figure 5 309 Flags 311 'x' - The x flag is reserved. It MUST be set to 0. 313 'E' - The E flag is used to indicate early-authentication. 315 The rest of the 4 bits (Resved) MUST be set to 0 and ignored on 316 reception. 318 SEQ 320 A 16-bit sequence number is used for replay protection. 322 TVs and TLVs 324 keyName-NAI: As defined in RFC 5296 [RFC5296], this is carried in a 325 TLV payload. The Type is 1. The NAI is variable in length, not 326 exceeding 253 octets. The username part of the NAI is the EMSKname 327 used identify the peer. The realm part of the NAI is the peer's home 328 domain name or the domain to which the peer is currently attached. 329 Exactly one keyName-NAI attribute SHALL be present in an EAP- 330 Initiate/Re-auth packet. 332 NAS-Identifier: As defined in RFC 5296 [RFC5296], it is carried in a 333 TLV payload. It is used to indicate the identifier of a CAP. Though 334 this document only introduces the case of a single CAP, two or more 335 NAS-Identifier may be included in the EAP-Initiate/Re-auth packet to 336 identify multiple CAPs. 338 Sequence number: It is carried in a TV payload. The Type is TBD 339 (which is lower than 128). It is used in the derivation of the pMSK 340 for each CAP to avoid multiple CAP using the same pMSK. Each NAS- 341 Identifier in the packet MUST be associated with a unique sequence 342 number. 344 Cryptosuite 346 This field indicates the integrity algorithm used for ERP/AAK. Key 347 lengths and output lengths are either indicated or are obvious from 348 the cryptosuite name. We specify some cryptosuites below: 350 0 RESERVED 352 1 HMAC-SHA256-64 354 2 HMAC-SHA256-128 356 3 HMAC-SHA256-256 358 HMAC-SHA256-128 is mandatory to implement and should be enabled in 359 the default configuration. 361 Authentication Tag 363 This field contains the integrity checksum over the ERP/AAK packet, 364 excluding the authentication tag field itself. The length of the 365 field is indicated by the Cryptosuite. 367 If the EAP-Initiate/Re-auth packet is not supported by the SAP, it is 368 discarded silently. 370 5.3. EAP-Finish/Re-auth extension 372 Figure 6 shows the changed parameters contained in the EAP-Finish/ 373 Re-auth packet defined in [RFC5296]. 375 0 1 2 3 376 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 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Code | Identifier | Length | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Type |R|x|L|E|Resved | SEQ | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | 1 or more TVs or TLVs ~ 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Cryptosuite | Authentication Tag ~ 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 Figure 6 389 Flags 391 'x' - The x flag is reserved. It MUST be set to 0. 393 'E' - The E flag is used to indicate early-authentication. 395 The rest of the 4 bits (Resved) MUST be set to 0 and ignored on 396 reception. 398 SEQ 400 A 16-bit sequence number is used for replay protection. 402 TVs and TLVs 404 keyName-NAI: As defined in[RFC5296], this is carried in a TLV 405 payload. The Type is 1. The NAI is variable in length, not 406 exceeding 253 octets. The realm part of the NAI is the home domain 407 name. Exactly one keyName-NAI attribute SHALL be present in an EAP- 408 Finish/Re-auth packet. 410 ERP/AAK-Key: It is carried in a TLV payload for the key container. 411 The type is TBD. One or more than one ERP/AAK-key may be present in 412 an EAP-Finish/Re-auth packet. 414 ERP/AAK-Key ::= 415 { sub-TLV: NAS-Identifier } 416 { sub-TLV: pMSK-lifetime } 417 { sub-TLV: pRK-lifetime } 418 { sub-TLV: Cryptosuites } 420 NAS-Identifier: It is carried in a sub-TLV payload. It is used to 421 indicate the identifier of candidate authenticator. There exactly 422 one instance of the NAS-Identifier TLV MUST be present in the ERP/ 423 AAK-Key TLV. 425 pMSK-lifetime: It is carried in a sub-TLV payload. The Type is 426 TBD. The value field is a 32-bit field and contains the lifetime 427 of the pMSK in seconds. If the 'L' flag is set, the pMSK Lifetime 428 attribute SHOULD be present. 430 pRK-lifetime: It is carried in a sub-TLV payload. The Type is 431 TBD. The value field is a 32-bit field and contains the lifetime 432 of the pRK in seconds. If the 'L' flag is set, the pRK Lifetime 433 attribute SHOULD be present. 435 List of Cryptosuites: This is a sub-TLV payload. The Type is TBD. 436 The value field contains a list of cryptosuites, each 1 octet in 437 length. The allowed cryptosuite values are as specified in 438 Section 5.2, above. The server SHOULD include this attribute if 439 the cryptosuite used in the EAP-Initiate/Re-auth message was not 440 acceptable and the message is being rejected. The server MAY 441 include this attribute in other cases. The server MAY use this 442 attribute to signal to the peer about its cryptographic algorithm 443 capabilities. 445 Cryptosuite 447 This field indicates the integrity algorithm and PRF used for ERP/ 448 AAK. Key lengths and output lengths are either indicated or are 449 obvious from the cryptosuite name. 451 Authentication Tag 453 This field contains the integrity checksum over the ERP/AAK packet, 454 excluding the authentication tag field itself. The length of the 455 field is indicated by the Cryptosuite. 457 5.4. TV/TLV and sub-TLV Attributes 459 The TV and TLV attributes are the same specified as section 5.3.4 of 460 [RFC5296]. In this document, some new TLV(s) which may be present in 461 the EAP-Initiate or EAP-Finish messages are defined as below: 463 Sequence number - This is a TV payload. The type is TBD. 465 ERP/AAK-Key - This is a TLV payload. The type is TBD. 467 The format of sub-TLV attributes that may be present in the EAP- 468 Initiate or EAP-Finish messages is: 470 0 1 2 3 471 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 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Type | Length | Value ... 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 The following types are defined in this document: 478 pRK Lifetime: This is a TV payload. The type of this sub-TLV is 479 TBD. 481 pMSK Lifetime: This is a TV payload. The type of this sub-TLV is 482 TBD. 484 List of Cryptosuites: This is a TLV payload. The type of this 485 sub-TLV is TBD. 487 6. Lower Layer Considerations 489 Similar to ERP, some lower layer specifications may need to be 490 revised to support ERP/AAK; refer to section 6 of [RFC5296] for 491 additional guidance. 493 7. AAA Transport Considerations 495 AAA transport of ERP/AAK messages is the same as AAA transport of the 496 ERP message [RFC5296]. In addition, the document requires AAA 497 transport of the ERP/AAK keying materials delivered by the ERP/AAK 498 server to the CAP. Hence, a new Diameter ERP/AAK application message 499 should be specified to transport the keying materials. 501 8. Security Considerations 503 This section provides an analysis of the protocol in accordance with 504 the AAA key management requirements specified in [RFC4962] 506 o Cryptographic algorithm independence: ERP-AAK satisfies this 507 requirement. The algorithm chosen by the peer is indicated in the 508 EAP-Initiate/Re-auth message. If the chosen algorithm is 509 unacceptable, the EAP server returns an EAP- Finish/Re-auth 510 message with Failure indication 512 o Strong, fresh session keys: ERP-AAK results in the derivation of 513 strong, fresh keys that are unique for the given CAP. An pMSK is 514 always derived on-demand when the peer requires a key with a new 515 CAP. The derivation ensures that the compromise of one pMSK does 516 not result in the compromise of a different pMSK at any time. 518 o Limit key scope: The scope of all the keys derived by ERP-AAK is 519 well defined. The pRK is used to derive the pIK and pMSK for the 520 CAP. Different sequence numbers for each CAP MUST be used to 521 derive the unique pMSK. 523 o Replay detection mechanism: For replay protection of ERP-AAK 524 messages, a sequence number associated with the pMSK is used. 526 o Authenticate all parties: The EAP Re-auth Protocol provides mutual 527 authentication of the peer and the server. The peer and SAP are 528 authenticated via ERP. The CAP is authenticated and trusted by 529 the SAP. 531 o Peer and authenticator authorization: The sequence number is 532 maintained by the peer and the server, and incremented by them 533 synchronously. 535 o Keying material confidentiality: The peer and the server derive 536 the keys independently using parameters known to each entity. 538 o Uniquely named keys: All keys produced within the ERP context can 539 be referred to uniquely as specified in this document. 541 o Prevent the domino effect: Different sequence numbers for each CAP 542 MUST be used to derive the unique pMSK. So the compromise of one 543 pMSK does not hurt any other CAP. 545 o Bind key to its context: the pMSK are binded to the context where 546 the sequence numbers are transmitted. 548 o Confidentiality of identity: this is the same with ERP protocol as 549 analyzed in [RFC5296]. 551 o Authorization restriction: All the keys derived are limited in 552 lifetime by that of the parent key or by server policy. Any 553 domain-specific keys are further restricted for use only in the 554 domain for which the keys are derived. Any other restrictions of 555 session keys may be imposed by the specific lower layer and are 556 out of scope for this specification. 558 9. IANA Considerations 560 New TLV types: 562 Sequence number 564 ERP/AAK-Key 566 New sub-TLV types: 568 pRK Lifetime 570 pMSK Lifetime 572 10. Acknowledgement 574 In writing this document, we have received reviews from many experts 575 in IETF, including Tom Taylor, Tena Zou, Tim Polk. We apologize if 576 we miss some names that have helped us. 578 11. References 580 11.1. Normative References 582 [RFC2119] Bradner, S., "Key words for use in 583 RFCs to Indicate Requirement Levels", 584 BCP 14, RFC 2119, March 1997. 586 [RFC5296] Narayanan, V. and L. Dondeti, "EAP 587 Extensions for EAP Re-authentication 588 Protocol (ERP)", RFC 5296, 589 August 2008. 591 11.2. Informative References 593 [I-D.ietf-dime-local-keytran] Zorn, G., Wu, W., and V. Cakulev, 594 "Diameter Attribute-Value Pairs for 595 Cryptographic Key Transport", 596 draft-ietf-dime-local-keytran-08 (work 597 in progress), October 2010. 599 [RFC3588] Calhoun, P., Loughney, J., Guttman, 600 E., Zorn, G., and J. Arkko, "Diameter 601 Base Protocol", RFC 3588, 602 September 2003. 604 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., 605 Carlson, J., and H. Levkowetz, 606 "Extensible Authentication Protocol 607 (EAP)", RFC 3748, June 2004. 609 [RFC4962] Housley, R. and B. Aboba, "Guidance 610 for Authentication, Authorization, and 611 Accounting (AAA) Key Management", 612 BCP 132, RFC 4962, July 2007. 614 [RFC5836] Ohba, Y., Wu, Q., and G. Zorn, 615 "Extensible Authentication Protocol 616 (EAP) Early Authentication Problem 617 Statement", RFC 5836, April 2010. 619 Authors' Addresses 621 Zhen Cao 622 China Mobile 623 53A Xibianmennei Ave., Xuanwu District 624 Beijing, Beijing 100053 625 P.R. China 627 EMail: zehn.cao@gmail.com 629 Hui Deng 630 China Mobile 631 53A Xibianmennei Ave., Xuanwu District 632 Beijing, Beijing 100053 633 P.R. China 635 EMail: denghui02@gmail.com 637 Yungui Wang 638 Huawei Technologies Co., Ltd. 639 Floor 10, HuiHong Mansion, No.91 BaiXia Rd. 640 Nanjing, Jiangsu 210001 641 P.R. China 643 Phone: +86 25 84565893 644 EMail: w52006@huawei.com 645 Qin Wu 646 Huawei Technologies Co., Ltd. 647 Floor 12, HuiHong Mansion, No.91 BaiXia Rd. 648 Nanjing, Jiangsu 210001 649 P.R. China 651 Phone: +86 25 84565892 652 EMail: sunseawq@huawei.com 654 Glen Zorn 655 Network Zen 656 227/358 Thanon Sanphawut 657 Bang Na, Bangkok 10260 658 Thailand 660 Phone: +66 (0) 87-040-4617 661 EMail: gwz@net-zen.net