idnits 2.17.1 draft-ietf-hokey-key-mgm-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 577. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 588. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 595. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 601. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 19, 2008) is 5668 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) == Unused Reference: 'RFC2548' is defined on line 509, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2548 ** Downref: Normative reference to an Informational RFC: RFC 3579 ** 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-01 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Ohba (Editor) 3 Internet-Draft Toshiba 4 Expires: April 22, 2009 October 19, 2008 6 Derivation, delivery and management of EAP based keys for handover and 7 re-authentication 8 draft-ietf-hokey-key-mgm-04 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 22, 2009. 35 Abstract 37 This document describes a mechanism for delivering a usage-specific 38 root key (USRK), a domain-specific root key (DSRK) and a usage- 39 specific domain-specific root key (USDSRK) using RADIUS. The root 40 keys are derived as part of an Extended Master Session Key (EMSK) 41 hierarchy in Extensible Authentication Protocol (EAP), and delivered 42 from a server to an intended third-party key holder. The mechanism 43 supports different scenarios for key delivery, depending on the type 44 of keys being delivered. The mechanism description includes the 45 definition for a key distribution exchange (KDE) protocol. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Key Delivery Architecture . . . . . . . . . . . . . . . . . . 4 52 4. Key Distribution Exchange (KDE) . . . . . . . . . . . . . . . 6 53 4.1. Context and scope for distributed keys . . . . . . . . . . 7 54 4.2. Key distribution exchange scenarios . . . . . . . . . . . 8 55 5. RADIUS KDE Attribute . . . . . . . . . . . . . . . . . . . . . 8 56 6. Conflicting Messages . . . . . . . . . . . . . . . . . . . . . 10 57 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 58 7.1. Requirements on RADIUS Key Transport . . . . . . . . . . . 11 59 7.2. Distributing Kpt without Peer Consent . . . . . . . . . . 11 60 8. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 12 61 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 62 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 63 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 65 11.2. Informative references . . . . . . . . . . . . . . . . . . 13 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 Intellectual Property and Copyright Statements . . . . . . . . . . 14 69 1. Introduction 71 The ability of the Extensible Authentication Protocol (EAP) framework 72 [RFC3748] to incorporate desired authentication methods and generate 73 master session keys (an MSK and an EMSK) [RFC5247] has led to the 74 idea of using the MSK and/or the EMSK for bootstrapping further keys 75 for a variety of security mechanisms. The MSK has been widely used 76 for bootstrapping the wireless link security associations between the 77 peer and the network attachment points. Issues arising from the use 78 of the MSK and the current bootstrapping methods when it comes to 79 mobility performance and security are described in [RFC5169]. The 80 EMSK is used for bootstrapping of keys for use cases that are not 81 covered by the use case of the MSK [RFC5295]. For instance [RFC5295] 82 defines a way to create a usage-specific root key (USRK) for 83 bootstrapping security for a specific use case. [RFC5295] also 84 defines ways to create domain-specific root keys for bootstrapping 85 security of a set of services within a domain. 87 Along with those lines, this document provides a specification of a 88 mechanism for secure delivery of such EMSK child keys from the EAP 89 server, holding the EMSK, to the intended third-party destinations by 90 using RADIUS [RFC2865], [RFC3579]. This document also describes 91 security requirements on delivery for this keying material over 92 RADIUS. 94 2. Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 USRK: Usage-Specific Root Key. A root key generated from the EMSK 101 and is used for a specific usage that is authorized for a peer, 102 following an EAP authentication. USRKs are domain independent. 104 USR-KH: USRK Holder. The USR-KH is responsible for receiving, 105 holding and protecting the USRK derived directly from the EMSK. 107 DSRK: Domain-Specific Root Key. A root key generated from the EMSK 108 and is used within a specific domain that EAP-authenticated peer 109 is authorized to receive services from or roam into. DSRKs are 110 usage independent. 112 DSR-KH: DSRK holder. The DSRK holder is responsible for receiving, 113 holding and protecting the DSRK derived directly from the EMSK. 115 DSUSRK: Domain-Specific Usage-Specific Root Key. A root key 116 generated from the DSRK and is used for a specific usage within a 117 specific domain that an EAP-authenticated peer is authorized to 118 receive services from. DSUSRKs are both usage and domain 119 dependent. 121 DSUSR-KH: DSRK holder. The DSUSRK holder is responsible for 122 receiving, holding and protection of the DSUSRK. 124 3. Key Delivery Architecture 126 The EAP server is only responsible for performing EAP authentication 127 and is not expected to be involved in any service authorization 128 decisions, nor is the EAP server aware of the future service requests 129 at the time of authentication. The authorization decisions based on 130 the user service profile and provisioning of services including 131 support for service security is expected to happen by third-parties, 132 such as AAA servers or service servers. When EAP-based keying is 133 used, such servers will cache and use the USRKs, DSRKs or DSUSRKs, 134 generated from the EMSK, as root keys for derivation of further keys 135 to secure the services they are providing. Thus they are considered 136 third-party key holders (KH) with respect to the initial two EAP 137 parties (EAP peer and server). However, since the EMSK cannot be 138 exported from the EAP server, such third-parties need to request the 139 EAP server to generate the relevant root key (e.g., a USRK) from the 140 EMSK and deliver the requested key to them. The third-party needs to 141 provide the required input data to be used along with the pseudo 142 random function (PRF) to the EAP server to generate the requested 143 key. The following types of top level key holders can be envisioned: 145 USRK holder (USR-KH): An entity acting as a recipient and then 146 holder of the usage-specific root key (USRK). The USR-KH is 147 responsible for derivation and distribution of any child keys 148 derived from the USRK for that specific usage. We assume that the 149 USR-KH and the EAP server are separate entities, logically if not 150 physically, and we specify the delivery of the USRK from EAP 151 server to USR-KH accordingly. 153 DSRK holder (DSR-KH): An entity acting as a recipient and then 154 holder of the domain-specific root key (DSRK). The DSR-KH is 155 responsible for derivation and distribution of any child keys 156 derived from the DSRK for that specific domain. The most likely 157 realization of a DSR-KH is a AAA server in the corresponding 158 domain, responsible for setting the policies for usage of the DSRK 159 within the domain. 161 DSUSRK holder (DSUSR-KH): An entity acting as a recipient and then 162 holder of the domain-specific usage-specific root key (DSUSRK) 163 delivered from the EAP server. The DSUSR-KH is responsible for 164 derivation and distribution of any child keys derived from the 165 DSUSRK for that specific domain and usage. The most likely 166 realization of a DSUSR-KH is a AAA server in the corresponding 167 domain, responsible for the service offered within the domain for 168 the specific usage at hand. 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | EAP server | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 / | \ \ 174 / | \ \ 175 USRK1 / | USRK2 \ USRK3 \ USRK4 176 (ABC) / | (XYZ) \(DSRK1) \ (DSRK2) 177 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 178 | USR-KH1 | | USR-KH2 | | DSR-KH1 | | DSR-KH2 | 179 | HOKEY server | | XYZ server| +-+-+-+-+-+ +-+-+-+-+-+ 180 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+ | | 181 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 182 | Domain 1 | | Domain 2 | 183 | DSUSR-KH1 | | DSUSR-KH2 | 184 |(home | |(visited | 185 | domain | | domain | 186 |HOKEY server)| |HOKEY server)| 187 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 189 +-+-+-+-+-+-+ 190 | peer | 191 +-+-+-+-+-+-+ 193 Figure 1: Key delivery for various EMSK child key cateories 195 USR-KHs and DSR-KHs are the top-level key holders where each key 196 holder has an interface with the EAP server. The interface between a 197 USR-KH and the EAP server is used for delivering usage-specific data 198 needed for generating a USRK to the EAP server and receiving the 199 resulting root key from the EAP server. Similary, the interface 200 between a DSR-KH and the EAP server is used for delivering domain- 201 specific data needed for generating a DSRK to the EAP server and 202 receiving the resulting root key from the EAP server. DSUSR-KHs are 203 considered a second-level key holder and has an interface with a 204 DSR-KH. 206 4. Key Distribution Exchange (KDE) 208 In the following we describe the generic mechanism for a key 209 distribution exchange (KDE), where a key is distributed from a 210 network server (with parent key holder) to a third-party. The 211 following shows a generic trust model for the key distribution 212 mechanism to the third-party. The peer (P) and a parent key holder, 213 called "server" (S) in this model share a parent key. The goal of 214 the keying solution is to use the parent key and generate a child key 215 (Kpt) to be shared between the peer and the third-party intermediary 216 (T). The peer is able to generate Kpt, but Kpt needs to be 217 distributed to a third-party intermediary (T). The goal of this 218 section is to provide a the general description of the KDE over 219 RADIUS for distribution of Kpt from S to T. It is required that the 220 communication path between the server (S) and the third-party (T) is 221 protected by use of an appropriate RADIUS transport security 222 mechanism (see Section 7). 224 +-+-+-+-+ +-+-+-+-+-+-+-+ 225 | | shared SA1 | | 226 | |------------------------------| server | 227 | Peer | | KH | 228 +-+-+-+-+ +-+-+-+-+-+-+-+ 229 | 230 +-+-+-+-+-+-+ V 231 | 3 rd party| | SA2 (Kpt) 232 | KH | ----------| 233 +-+-+-+-+-+-+ 235 Figure 2: Distribution of a child key from a parent key key holder to 236 a 3rd party child key key holder 238 The key distribution to a third-party consists of 1 exchange, i.e. 2 239 messages between the third-party and the server. A RADIUS KDE 240 attribute is introduced for this exchange (see Section 5. A KDE- 241 Request is sent by the third-party as a RADIUS Access-Request message 242 with a KDE attribute with K-flag cleared. A KDE-Response is sent by 243 the server as a RADIUS Access-Accept message with a KDE attribute 244 with K-flag set. 246 Third-Party Server 247 -------- ------- 248 | | 249 | | 250 | KDE-Request (TRT) | 251 | (i.e., RADIUS Access-Request{KDE(K=0)}) | 252 |----------------------------------------->| 253 | KDE-Response(TOK) | 254 | (i.e., RADIUS Access-Accept{KDE(K=1)}) | 255 |<-----------------------------------------| 257 Figure 3: KDE Exchange 259 KDE-Request: Third-party sends a third party request token (TRT) to 260 the server. The contents of TRT are detailed below. 262 KDE-Response: Server sends the Kpt to third-party wrapped inside a 263 token called Key Token (TOK). 265 TRT : (PID, KT, KL) 267 TRT (Third-party Request Token) carries the identifiers of the 268 peer (PID) as well as the key type (KT) and the key label (KL). 269 See [RFC5295] for the specification of key labels. 271 TOK : (KT, KL, Kpt, KN_Kpt, LT_Kpt) 273 TOK (Key Token) carries the key to be distributed to the third- 274 party (Kpt). LT_Kpt is the key lifetime for a Kpt. 276 4.1. Context and scope for distributed keys 278 The key lifetime of each distributed key MUST NOT be greater than 279 that of its parent key. 281 The key context of each distributed key is determined by the sequence 282 of KTs in the key hierarchy. When a DSRK is being delivered and the 283 DSRK applies to only a specific set of services, the service types 284 may need to be carried as part of context for the key. Carrying such 285 a specific set of services are outside the scope of this document. 287 The key scope of each distributed key is determined by the sequence 288 of (PID, KT, KL)-tuples in the key hierarchy. The Key Derivation 289 Function (KDF) used to generate the keys includes context and scope 290 information that binds the key to the specific channel [RFC5295]. 292 4.2. Key distribution exchange scenarios 294 There are three scenarios for distribution of EMSK child keys third- 295 parties. We assume that the peer and the EAP server have mutually 296 authenticated to each other using an EAP method and have generated an 297 EMSK. For all scenarios, the trigger and mechanism for key delivery 298 may involve a specific request from the peer and another intermediary 299 (such as authenticator). For simplicity, we assume that USR-KHs 300 reside in the same domain as the EAP server. 302 Scenario 1: EAP server to USR-KH: In this scenario, an EAP server 303 delivers a USRK to a USR-KH. 305 Scenario 2: EAP server to DSR-KH: In this scenario, an EAP server 306 delivers a DSRK to a DSR-KH. 308 Scenario 3: DSR-KH to DSUSR-KH: In this scenario, a DSR-KH in a 309 specific domain delivers keying material to the DSUSR-KH in the 310 same domain. 312 The key distribution exchanges for Scenario 3 can be combined with 313 the key distribution exchanges for Scenario 2 into a single roundtrip 314 exchange as shown in Figure 4. KDE-Request and KDE-Response are 315 messages for Scenarios 2. KDE-Request' and KDE-Response' are 316 messages for Scenarios 3. 318 DSUSR-KH DSR-KH EAP Server 319 -------- ------- ----- 320 | KDE-Request'(TRT') | KDE-Request(TRT) | 321 |------------------------>|-------------------------->| 322 | KDE-Response'(TOK') | KDE-Response(TOK) | 323 |<----------------------- |<--------------------------| 324 | | | 326 Figure 4: Combined Message Exchange 328 5. RADIUS KDE Attribute 330 A RADIUS Key Distribution Exchange (KDE) attribute has the following 331 format. See Section 7 for security requirements on transporting this 332 RADIUS attribute. 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Type | Length |K| Reserved | Key Type | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Key Label ... 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Key Name (included only when K=1) ... 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Key (included only when K=1) ... 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Key Lifetime (included only when K=1) | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 Type 350 = X (KDE) [X to be assigned by IANA]. 352 Length 354 >4 356 K (Key included) 358 A flag to indicate whether this attribute contains a Key field. 359 This flag is set for a KDE-Response. This flag is cleared for a 360 KDE-Request. 362 Reserved 364 Reserved bits. All reserved bits MUST be set to 0 by the sender 365 and ignored by the recipient. 367 Key Type 369 A field to contain a KT. The following KT values are defined: 0 370 (DSRK), 1 (USRK) and 2 (DSUSRK). 372 Key Label 374 A field to contain a key label (KL). The first octet contains the 375 length of the rest of this field in octets. 377 Key Name 379 A field to contain a KN_Kpt. The first octet contains the length 380 of the rest of this field in octets. This field is contained if 381 and only if K-flag is set. 383 Key 385 A field to contain a Kpt. The first octet contains the length of 386 the rest of this field in octets. This field is contained if and 387 only if K-flag is set. 389 Key Lifetime 391 A 4-octet unsigned integer to indicate a LT_Kpt. This field is 392 contained if and only if K-flag is set. 394 A KDE-Request, i.e., an RADIUS Access-Request message carrying a KDE 395 attribute with K-flag cleared, is transmitted by the third-party in 396 one of the following cases. One case is for explicit ERP 397 bootstrapping [RFC5296] in which an EAP-Initiate and EAP-Finish 398 exchange is performed between the peer and the home AAA server, with 399 the bootstrapping flag in the EAP-Initiate message set. In this 400 case, the third-party that requests a Kpt MUST include a KDE 401 attribute with K-bit cleared in a RADIUS Access-Request message that 402 carries an EAP-Initiate message with the bootstrapping flag turned on 403 [RFC5296]. Another case is implicit ERP bootstrapping [RFC5296] in 404 which Kpt key distribution occurs during initial EAP authentication. 405 In this case, the third-party that requests a Kpt MUST include a KDE 406 attribute with K-flag cleared in the RADIUS Access-Request message 407 that carries the first EAP-Response message from the peer. In both 408 cases, a value of the RADIUS User-Name attribute is used as the PID. 410 A KDE-Response, i.e., an RADIUS Access-Accept message carrying a KDE 411 attribute with K-flag set, is transmitted by a server in one of the 412 following ways. In the case of explicit ERP bootstrapping, the 413 server MUST include a KDE attribute with K-flag set in a RADIUS 414 Access-Accept message that carries an EAP-Finish message [RFC5296] 415 for which the bootstrapping flag is set. In the case of implicit ERP 416 bootstrapping, the server that received a valid KDE-Request includes 417 a KDE attribute with K-flag set in a RADIUS Access-Accept message 418 that carries an EAP-Success. 420 6. Conflicting Messages 422 In addition to the rules specified in Section 2.6.3. of [RFC3579], 423 the following combinations SHOULD NOT be sent by a RADIUS Server: 425 Access-Accept/EAP-Message/EAP-Finish with 'R' flag set to 1 427 Access-Reject/EAP-Message/EAP-Finish with 'R' flag set to 0 429 Access-Reject/Keying-Material 431 Access-Reject/KDE 433 Access-Challenge/EAP-Message/EAP-Initiate 435 Access-Challenge/EAP-Message/EAP-Finish 437 Access-Challenge/KDE 439 7. Security Considerations 441 This section provides security requirements and an analysis on 442 transporting EAP keying material using RADIUS. 444 7.1. Requirements on RADIUS Key Transport 446 RADIUS messages that carry a KDE attribute MUST be encrypted and 447 integrity and replay protected with a security association created by 448 a RADIUS transport protocol such as TLS [I-D.ietf-radext-radsec]. 449 When there is an intermediary such as a RADIUS proxy on the path 450 between the third-party and the server, there will be a series of 451 hop-by-hop security associations along the path. The use of hop-by- 452 hop security associations implies that the intermediary on each hop 453 can access the distributed keying material. Hence the use of hop-by- 454 hop security SHOULD be limited to an environment where an 455 intermediary is trusted not to use the distributed key material. 457 7.2. Distributing Kpt without Peer Consent 459 When a KDE-Request message is sent as a result of explicit ERP 460 bootstrapping [RFC5296], cryptographic verification of peer consent 461 on distributing a Kpt is provided by the integrity checksum of the 462 EAP-Initiate message with the bootstrapping flag turned on. 464 When a KDE-Request message is sent as a result of implicit ERP 465 bootstrapping [RFC5296], cryptographic verification of peer consent 466 on distributing a Kpt is not provided. As a result, it is possible 467 for a third-party to request a Kpt from the server and obtain the Kpt 468 even if a peer actually does not support ERP, which can lead to an 469 unintended use of a Kpt. 471 8. IANA consideration 473 This document defines a new namespace for maintaining Key Type used 474 to identify the type of Kpt. The range of values 0 - 255 are for 475 permanent, standard message types, allocated by IETF Review [IANA]. 476 This document defines the values 0 (DSRK) 1 (USRK) and 2 (DSUSRK). 478 This document defines a new RADIUS Attribute Type for KDE defined in 479 Section 5. 481 9. Acknowledgements 483 The author would like to thank Dan Harkins, Chunqiang Li, Rafael 484 Marin Lopez and Charles Clancy for their valuable comments. 486 10. Contributors 488 The following people contributed to this document. 490 Madjid Nakhjiri (madjid.nakhjiri@motorola.com) 492 Yoshihiro Ohba (yohba@tari.toshiba.com) 494 Kedar Gaonkar (kgaonkar3@gatech.edu) 496 Lakshminath Dondeti (ldondeti@qualcomm.com) 498 Vidya Narayanan (vidyan@qualcomm.com) 500 Glen Zorn (glenzorn@comcast.net) 502 11. References 504 11.1. Normative References 506 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 507 Requirement Levels", BCP 14, RFC 2119, March 1997. 509 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 510 RFC 2548, March 1999. 512 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 513 "Remote Authentication Dial In User Service (RADIUS)", 514 RFC 2865, June 2000. 516 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 517 Dial In User Service) Support For Extensible 518 Authentication Protocol (EAP)", RFC 3579, September 2003. 520 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 521 Levkowetz, "Extensible Authentication Protocol (EAP)", 522 RFC 3748, June 2004. 524 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 525 "Specification for the Derivation of Root Keys from an 526 Extended Master Session Key (EMSK)", RFC 5295, 527 August 2008. 529 [RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- 530 authentication Protocol (ERP)", RFC 5296, August 2008. 532 [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an 533 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 534 May 2008. 536 11.2. Informative references 538 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 539 Authentication Protocol (EAP) Key Management Framework", 540 RFC 5247, August 2008. 542 [RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti, 543 "Handover Key Management and Re-Authentication Problem 544 Statement", RFC 5169, March 2008. 546 [I-D.ietf-radext-radsec] 547 Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 548 "TLS encryption for RADIUS over TCP (RadSec)", 549 draft-ietf-radext-radsec-01 (work in progress), 550 August 2008. 552 Author's Address 554 Yoshihiro Ohba 555 Toshiba America Research, Inc. 556 1 Telcordia Drive 557 Piscataway, NJ 08854 558 USA 560 Phone: +1 732 699 5305 561 Email: yohba@tari.toshiba.com 563 Full Copyright Statement 565 Copyright (C) The IETF Trust (2008). 567 This document is subject to the rights, licenses and restrictions 568 contained in BCP 78, and except as set forth therein, the authors 569 retain all their rights. 571 This document and the information contained herein are provided on an 572 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 573 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 574 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 575 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 576 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 577 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 579 Intellectual Property 581 The IETF takes no position regarding the validity or scope of any 582 Intellectual Property Rights or other rights that might be claimed to 583 pertain to the implementation or use of the technology described in 584 this document or the extent to which any license under such rights 585 might or might not be available; nor does it represent that it has 586 made any independent effort to identify any such rights. Information 587 on the procedures with respect to rights in RFC documents can be 588 found in BCP 78 and BCP 79. 590 Copies of IPR disclosures made to the IETF Secretariat and any 591 assurances of licenses to be made available, or the result of an 592 attempt made to obtain a general license or permission for the use of 593 such proprietary rights by implementers or users of this 594 specification can be obtained from the IETF on-line IPR repository at 595 http://www.ietf.org/ipr. 597 The IETF invites any interested party to bring to its attention any 598 copyrights, patents or patent applications, or other proprietary 599 rights that may cover technology that may be required to implement 600 this standard. Please address the information to the IETF at 601 ietf-ipr@ietf.org.