idnits 2.17.1 draft-ietf-hokey-key-mgm-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 25, 2009) is 5539 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) ** Obsolete normative reference: RFC 5226 (ref. 'IANA') (Obsoleted by RFC 8126) == Outdated reference: A later version (-12) exists of draft-ietf-radext-radsec-03 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Hoeper (Editor) 3 Internet-Draft Motorola 4 Intended status: Standards Track Y. Ohba (Editor) 5 Expires: August 29, 2009 Toshiba 6 February 25, 2009 8 Derivation, delivery and management of EAP based keys for handover and 9 re-authentication 10 draft-ietf-hokey-key-mgm-05 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on August 29, 2009. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. 56 Abstract 58 This document describes a mechanism for delivering root keys from an 59 Extensible Authentication Protocol (EAP) server to another network 60 server that requires the keys for offering security protected 61 services, such as re-authentication, to an EAP peer. The distributed 62 root key can be either a usage-specific root key (USRK), a domain- 63 specific root key (DSRK) or a usage-specific domain-specific root key 64 (USDSRK) that has been derived from an Extended Master Session Key 65 (EMSK) hierarchy previously established between the EAP server and an 66 EAP peer. The document defines a key distribution exchange (KDE) 67 protocol using Remote Authentication Dial In User Service (RADIUS) 68 that can distribute these different types of root keys and discusses 69 its security requirements. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3. Key Delivery Architecture . . . . . . . . . . . . . . . . . . 5 76 4. Key Distribution Exchange (KDE) . . . . . . . . . . . . . . . 7 77 4.1. Context and Scope for Distributed Keys . . . . . . . . . . 8 78 4.2. Key Distribution Exchange Scenarios . . . . . . . . . . . 8 79 5. RADIUS KDE Attribute . . . . . . . . . . . . . . . . . . . . . 9 80 6. KDE used in the EAP Re-authentication Protocol (ERP) . . . . . 10 81 7. Conflicting Messages . . . . . . . . . . . . . . . . . . . . . 11 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 8.1. Requirements on RADIUS Key Transport . . . . . . . . . . . 11 84 8.2. Distributing RK without Peer Consent . . . . . . . . . . . 12 85 9. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 12 86 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 87 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 89 12.1. Normative References . . . . . . . . . . . . . . . . . . . 13 90 12.2. Informative references . . . . . . . . . . . . . . . . . . 13 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 93 1. Introduction 95 The Extensible Authentication Protocol (EAP) [RFC3748] is an 96 authentication framework supporting authentication methods that are 97 specified in EAP methods. By definition, any key-generating EAP 98 method derives an Master Session Key (MSK) and an Extended Master 99 Session Key (EMSK). [RFC5295] reserves the EMSK for the sole purpose 100 of deriving root keys that can be used for specific purposes called 101 usages. In particular, [RFC5295] defines how to create a usage- 102 specific root key (USRK) for bootstrapping security in a specific 103 application, a domain-specific root key (DSRK) for bootstrapping 104 security of a set of services within a domain, and a usage-specific 105 DSRK (USDSRK) for a specific application within a domain. 107 MSK and EMSK may be used to derive further keying material for a 108 variety of security mechanisms [RFC5247]. For example, the MSK has 109 been widely used for bootstrapping the wireless link security 110 associations between the peer and the network attachment points. 111 However, performance as well as security issues arise when using the 112 MSK and the current bootstrapping methods in mobile scenarios that 113 require handovers, as described in [RFC5169]. To address handover 114 latencies and other shortcomings, [RFC5296] specifies an EAP re- 115 authentication protocol (ERP) that uses keys derived from EMSK or 116 DSRK to enable efficient re-authentications in handover scenarios. 117 [RFC5295] and [RFC5296] both do not specify how root keys are 118 delivered to the network server requiring the key. Such a key 119 delivery mechanism is essential because the EMSK cannot leave the EAP 120 server ([RFC5295]) but root keys are needed by other network servers 121 disjoint with the EAP server. For example, in order to enable an EAP 122 peer to re-authenticate to a network during a handover, certain root 123 keys need to be made available by the EAP server to the server 124 carrying out the re-authentication. 126 This document specifies a mechanism for the delivery of EMSK child 127 keys from the server holding the EMSK or a root key to another 128 network server that requests a root key for providing protected 129 services (such as re-authentication and other usage and domain- 130 specific services) to EAP peers. In the remainder of this document, 131 a server delivering root keys is referred to as Key Delivering Server 132 (KDS) and a server authorized to request and receive root keys from a 133 KDS is referred to as Key Requesting Server (KRS). The Key 134 Distribution Exchange (KDE) protocol defined in this document uses 135 RADIUS [RFC2865], [RFC3579] and has several variants depending on the 136 type of key that is requested and delivered (i.e. DRSK, USRK, and 137 USDSRK). The document also describes security requirements for the 138 secure key delivery over RADIUS. 140 2. Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119]. 146 USRK: Usage-Specific Root Key. A root key that is derived from the 147 EMSK, see [RFC5295]. 149 USR-KH: USRK Holder. A network server that is authorized to request 150 and receive a USRK from the EAP server. The USR-KH can be an AAA 151 server or dedicated service server. 153 DSRK: Domain-Specific Root Key. A root key that is derived from the 154 EMSK, see [RFC5295]. 156 DSR-KH: DSRK Holder. A network server that is authorized to request 157 and receive a DSRK from the EAP server. The most likely 158 implementation of a DSR-KH is an AAA server in a domain, enforcing 159 the policies for the usage of the DSRK within this domain. 161 DSUSRK: Domain-Specific Usage-Specific Root Key. A root key that is 162 derived from the DSRK, see [RFC5295]. 164 DSUSR-KH: DSUSRK holder. A network server authorized to request and 165 receive a DSUSRK from the DSR-KH. The most likely implementation 166 of a DSUSR-KH is an AAA server in a domain, responsible for a 167 particular service offered within this domain. 169 RK: Root Key. An EMSK child key, i.e. a USRK, DSRK, or DSUSRK. 171 KDS: Key Delivering Server. A network server that holds an EMSK or 172 DSRK and delivers root keys to KRS requesting root keys. The EAP 173 server and DSR-KH can act as KDS. 175 KRS: Key Requesting Server. A network server that shares an 176 interface with a KDS and is authorized to request root keys from 177 the KDS. USR-KH, DSR-KH, and DSUSR-KH can all act as KRS. 179 3. Key Delivery Architecture 181 An EAP server carries out the EAP authentications with EAP peers but 182 is typically not making any, potentially future, service 183 authorization decisions involving peers. Authorizations as well as 184 the service provisioning are handled by the respective network server 185 offering the requested service. These servers can be AAA servers or 186 other service servers. Whenever EAP-based keying material is used to 187 protect a requested service, a network server needs to request the 188 root key associated with the offered service from the respective KDS. 189 This kind of key requests and distributions are necessary because an 190 EMSK cannot leave the EAP server ([RFC5295]). Hence, any root key 191 that is directly derived from an EMSK must be derived and delivered 192 by the EAP server itself, whereas root keys derived from EMSK child 193 keys, such as a DSUSRK, can be requested from the respective root key 194 holder. Hence, a KDS can be either the EAP server or a DSRK holder 195 (DSR-KH), whereas a KRS can be either a USRK holder (USR-KH), a 196 DSR-KH or a DSUSRK holder (DSUSR-KH). 198 The KRS needs to share an interface with the KDS to be able to send 199 all necessary input data to derive the requested key and to receive 200 the requested key. The provided data includes the Key Derivation 201 Function (KDF) that should be used to derive the requested key. The 202 KRS uses the received root key to derive further keying material in 203 order to secure its offered services. Every KDS is responsible for 204 storing and protecting the received root key as well as the 205 derivation and distribution of any child key derived from the root 206 key. An example of a key delivery architecture is illustrated in 207 Figure 1 showing the different types of KRS and their interfaces to 208 the KDS. 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | EAP server | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 / | | \ 214 / | | \ 215 / | | \ 216 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 217 | USR-KH1 | | USR-KH2 | | DSR-KH1 | | DSR-KH2 | 218 | HOKEY server| | XYZ server| |Domain 1 | | Domain 2| 219 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 220 / | 221 / | 222 / | 223 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 224 | DSUSR-KH | | DSUSR-KH2 | 225 | Domain 1 | | Domain 2 | 226 |Home domain | |Visited domain | 227 |HOKEY server | |HOKEY server | 228 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 230 Figure 1: Example Key Delivery Architecture for the Different KRS and 231 KDS 233 4. Key Distribution Exchange (KDE) 235 In this section, a generic mechanism for a key distribution exchange 236 (KDE)over RADIUS is described in which a root key (RK) is distributed 237 from a KDS to a KRS. It is required that the communication path 238 between the KDS and the KRS is protected by the use of an appropriate 239 RADIUS transport security mechanism (see Section 8). Here, it is 240 assumed that the KRS and the KDS are separate entities, logically if 241 not physically, and the delivery of the requested RK is specified 242 accordingly. 244 The key distribution exchange consists of one roundtrip, i.e. two 245 messages between the KRS and the KDS, as illustrated in Figure 2. 246 First, the KRS sends a KDE-Request consisting of a RADIUS Access- 247 Request message with a KDE attribute in which the K-flag is cleared. 248 As a response, the KDS sends a KDE-Response consisting of a RADIUS 249 Access-Accept message with a KDE attribute in which the K-flag set. 250 The RADIUS KDE attribute used in this exchange is defined in 251 Section 5. 253 KRS KDS 254 -------- ------- 255 | | 256 | | 257 | KDE-Request (KRT) | 258 | (i.e., RADIUS Access-Request{KDE(K=0)}) | 259 |----------------------------------------->| 260 | KDE-Response(KDT) | 261 | (i.e., RADIUS Access-Accept{KDE(K=1)}) | 262 |<-----------------------------------------| 264 Figure 2: KDE Message Flow 266 KDE-Request: The KRS sends a Key Request Token (KRT) to the KDS. 267 The contents of KRT are detailed below. 269 KDE-Response: As a response, the KDS sends the requested RK to the 270 KRS wrapped inside a token called Key Delivery Token (KDT). The 271 contents of KDT are detailed below. 273 KRT : (PID, KT, KL) 275 KRT carries the identifiers of the peer (PID), the key type (KT) 276 and the key label (KL). See [RFC5295] for the specification of 277 key labels. 279 KDT : (KT, KL, RK, KN_RK, LT_RK) 281 KDT carries the root key (RK) to be distributed to the KRS, as 282 well as the key type (KT), the key label (KL), the key name 283 (KN_RK) and the lifetime of RK (LT_RK). 285 4.1. Context and Scope for Distributed Keys 287 The key lifetime of each distributed key MUST NOT be greater than 288 that of its parent key. 290 The key context of each distributed key is determined by the sequence 291 of KTs in the key hierarchy. When a DSRK is being delivered and the 292 DSRK applies to only a specific set of services, the service types 293 may need to be carried as part of context for the key. Carrying such 294 a specific set of services is outside the scope of this document. 296 The key scope of each distributed key is determined by the sequence 297 of (PID, KT, KL)-tuples in the key hierarchy. The KDF used to 298 generate the requested keys includes context and scope information, 299 thus, binding the key to the specific channel [RFC5295]. 301 4.2. Key Distribution Exchange Scenarios 303 Given the three types of KRS, there are three scenarios for the 304 distribution of EMSK child keys. For all scenarios, the trigger and 305 mechanism for key delivery may involve a specific request from an EAP 306 peer and/or another intermediary (such as an authenticator). For 307 simplicity, it is assumed that USR-KHs reside in the same domain as 308 the EAP server. 310 Scenario 1: EAP server to USR-KH: In this scenario, the EAP server 311 delivers a USRK to a USR-KH. 313 Scenario 2: EAP server to DSR-KH: In this scenario, the EAP server 314 delivers a DSRK to a DSR-KH. 316 Scenario 3: DSR-KH to DSUSR-KH: In this scenario, a DSR-KH in a 317 specific domain delivers keying material to a DSUSR-KH in the same 318 domain. 320 The key distribution exchanges for Scenario 3 can be combined with 321 the key distribution exchanges for Scenario 2 into a single roundtrip 322 exchange as shown in Figure 3. Here, KDE-Request and KDE-Response 323 are messages for Scenarios 2, whereas KDE-Request' and KDE-Response' 324 are messages for Scenarios 3. 326 DSUSR-KH DSR-KH EAP Server 327 -------- ------- ----- 328 | KDE-Request'(KRT') | KDE-Request(KRT) | 329 |------------------------>|-------------------------->| 330 | KDE-Response'(KDT') | KDE-Response(KDT) | 331 |<----------------------- |<--------------------------| 332 | | | 334 Figure 3: Combined Message Exchange 336 5. RADIUS KDE Attribute 338 This section defines the format of the RADIUS KDE attribute. See 339 Section 8 for security requirements on transporting this RADIUS 340 attribute. 342 0 1 2 3 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Type | Length |K| Reserved | Key Type | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Key Label | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Key Name (included only when K=1) | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Key (included only when K=1) | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Key Lifetime (included only when K=1) | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 Type 358 = X (KDE) [X to be assigned by IANA]. 360 Length 362 >4 364 K (Key included) 366 A flag to indicate whether this attribute contains a Key field. 367 This flag is set for a KDE-Response. This flag is cleared for a 368 KDE-Request. 370 Reserved 372 Reserved bits. All reserved bits MUST be set to 0 by the sender 373 and ignored by the recipient. 375 Key Type 377 A field to contain a KT. The following KT values are defined: 0 378 (DSRK), 1 (USRK) and 2 (DSUSRK). 380 Key Label 382 A field to contain a key label (KL). The first octet contains the 383 length of the rest of this field in octets. 385 Key Name 387 A field to contain a KN_RK. The first octet contains the length 388 of the rest of this field in octets. This field is contained if 389 and only if K-flag is set. 391 Key 393 A field to contain a RK. The first octet contains the length of 394 the rest of this field in octets. This field is contained if and 395 only if K-flag is set. 397 Key Lifetime 399 A 4-octet unsigned integer to indicate a LT_RK. This field is 400 contained if and only if K-flag is set. 402 6. KDE used in the EAP Re-authentication Protocol (ERP) 404 This section describes how the presented KDE should be used to 405 request and deliver the root keys used for re-authentication in the 406 EAP Re-authentication Protocol (ERP) defined in [RFC5296]. ERP 407 supports two forms of bootstrapping, implicit as well as explicit 408 bootstrapping, and KDE is discussed for both cases in the remainder 409 of this section. 411 In implicit bootstrapping the local EAP Re-authentication (ER) server 412 requests the DSRK from the home AAA server during the initial EAP 413 exchange. Here, the local ER server acts as the KRS and the home AAA 414 server as the KDS. In this case, the local ER server requesting the 415 DSRK MUST include a KDE attribute with the K-flag cleared in the 416 RADIUS Access-Request message that carries the first EAP-Response 417 message from the peer. A value of the RADIUS User-Name attribute is 418 used as the PID. Upon receiving a valid KDE-Request, the home AAA 419 server includes a KDE attribute with K-flag set in the RADIUS Access- 420 Accept message that carries the EAP-Success message. 422 Explicit bootstrapping is initiated by a peer if it doesn't know the 423 domain. Here, EAP-Initiate and EAP-Finish messages are exchanged 424 between the peer and the home AAA server, with the bootstrapping flag 425 in the EAP-Initiate message set. In this case, the local ER server 426 (acting as KRS) MUST include a KDE attribute with the K-bit cleared 427 in a RADIUS Access-Request message that carries an EAP-Initiate 428 message with the bootstrapping flag turned on. A value of the RADIUS 429 User-Name attribute is used as the PID. In its response, the home 430 AAA server (acting as KDS) MUST include a KDE attribute with K-flag 431 set in a RADIUS Access-Accept message that carries an EAP-Finish 432 message for which the bootstrapping flag is set. 434 7. Conflicting Messages 436 In addition to the rules specified in Section 2.6.3. of [RFC3579], 437 the following combinations SHOULD NOT be sent by a RADIUS Server: 439 Access-Accept/EAP-Message/EAP-Finish with 'R' flag set to 1 440 Access-Reject/EAP-Message/EAP-Finish with 'R' flag set to 0 441 Access-Reject/Keying-Material 442 Access-Reject/KDE 443 Access-Challenge/EAP-Message/EAP-Initiate 444 Access-Challenge/EAP-Message/EAP-Finish 445 Access-Challenge/KDE 447 8. Security Considerations 449 This section provides security requirements and an analysis on 450 transporting EAP keying material using RADIUS. 452 8.1. Requirements on RADIUS Key Transport 454 RADIUS messages that carry a KDE attribute MUST be encrypted, 455 integrity-protected and replay-protected with a security association 456 created by a RADIUS transport protocol such as TLS 457 [I-D.ietf-radext-radsec]. When there is an intermediary such as a 458 RADIUS proxy on the path between the KRS and the KDS, there will be a 459 series of hop-by-hop security associations along the path. The use 460 of hop-by-hop security associations implies that the intermediary on 461 each hop can access the distributed keying material. Hence the use 462 of hop-by-hop security SHOULD be limited to an environment where an 463 intermediary is trusted not to abuse the distributed key material. 465 8.2. Distributing RK without Peer Consent 467 When a KDE-Request message is sent as a result of explicit ERP 468 bootstrapping [RFC5296], cryptographic verification of peer consent 469 on distributing a RK is provided by the integrity checksum of the 470 EAP-Initiate message with the bootstrapping flag turned on. 472 When a KDE-Request message is sent as a result of implicit ERP 473 bootstrapping [RFC5296], cryptographic verification of peer consent 474 on distributing a RK is not provided. As a result, it is possible 475 for a KRS to request a RK from the home server and obtain the RK even 476 if the peer does not support ERP, which can lead to an unintended use 477 of a RK and failed authentication attempts. 479 9. IANA consideration 481 This document defines a new namespace for maintaining Key Type used 482 to identify the type of the root key RK. The range of values 0 - 255 483 are for permanent, standard message types, allocated by IETF Review 484 [IANA]. This document defines the values 0 (DSRK), 1 (USRK) and 2 485 (DSUSRK). 487 This document defines a new RADIUS Attribute Type for KDE in 488 Section 5. 490 10. Acknowledgements 492 The author would like to thank Dan Harkins, Chunqiang Li, Rafael 493 Marin Lopez and Charles Clancy for their valuable comments. 495 11. Contributors 497 The following people contributed to this document. 499 Madjid Nakhjiri (madjid.nakhjiri@motorola.com) 501 Yoshihiro Ohba (yohba@tari.toshiba.com) 503 Kedar Gaonkar (kgaonkar3@gatech.edu) 505 Lakshminath Dondeti (ldondeti@qualcomm.com) 507 Vidya Narayanan (vidyan@qualcomm.com) 509 Glen Zorn (glenzorn@comcast.net) 511 12. References 513 12.1. Normative References 515 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 516 Requirement Levels", BCP 14, RFC 2119, March 1997. 518 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 519 "Remote Authentication Dial In User Service (RADIUS)", 520 RFC 2865, June 2000. 522 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 523 Levkowetz, "Extensible Authentication Protocol (EAP)", 524 RFC 3748, June 2004. 526 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 527 "Specification for the Derivation of Root Keys from an 528 Extended Master Session Key (EMSK)", RFC 5295, 529 August 2008. 531 [RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- 532 authentication Protocol (ERP)", RFC 5296, August 2008. 534 [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an 535 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 536 May 2008. 538 12.2. Informative references 540 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 541 Dial In User Service) Support For Extensible 542 Authentication Protocol (EAP)", RFC 3579, September 2003. 544 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 545 Authentication Protocol (EAP) Key Management Framework", 546 RFC 5247, August 2008. 548 [RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti, 549 "Handover Key Management and Re-Authentication Problem 550 Statement", RFC 5169, March 2008. 552 [I-D.ietf-radext-radsec] 553 Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 554 "TLS encryption for RADIUS over TCP (RadSec)", 555 draft-ietf-radext-radsec-03 (work in progress), 556 February 2009. 558 Authors' Addresses 560 Katrin Hoeper 561 Motorola 562 1301 E Algonquin Road 563 Schaumburg, IL 60196 564 USA 566 Phone: +1 847 576 4714 567 Email: khoeper@motorola.com 569 Yoshihiro Ohba 570 Toshiba America Research, Inc. 571 1 Telcordia Drive 572 Piscataway, NJ 08854 573 USA 575 Phone: +1 732 699 5305 576 Email: yohba@tari.toshiba.com