idnits 2.17.1 draft-ietf-hokey-key-mgm-11.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 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 (November 30, 2009) is 5260 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 informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Hoeper, Ed. 3 Internet-Draft Motorola 4 Intended status: Standards Track Y. Ohba, Ed. 5 Expires: June 3, 2010 Toshiba 6 M. Nakhjiri 7 Motorola 8 November 30, 2009 10 Distribution of EAP based keys for handover and re-authentication 11 draft-ietf-hokey-key-mgm-11 13 Abstract 15 This document describes an abstract mechanism for delivering root 16 keys from an Extensible Authentication Protocol (EAP) server to 17 another network server that requires the keys for offering security 18 protected services, such as re-authentication, to an EAP peer. The 19 distributed root key can be either a usage-specific root key (USRK), 20 a domain-specific root key (DSRK) or a domain-specific usage-specific 21 root key (DSUSRK) that has been derived from an Extended Master 22 Session Key (EMSK) hierarchy previously established between the EAP 23 server and an EAP peer. The document defines a template for a key 24 distribution exchange (KDE) protocol that can distribute these 25 different types of root keys using an AAA (Authentication, 26 Authorization and Accounting) protocol and discusses its security 27 requirements. The described protocol template does not specify 28 message formats, data encoding, or other implementation details. It 29 thus needs to be instantiated with a specific protocol (e.g. RADIUS 30 or Diameter) before it can be used. 32 Status of this Memo 34 This Internet-Draft is submitted to IETF in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt. 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html. 53 This Internet-Draft will expire on June 3, 2010. 55 Copyright Notice 57 Copyright (c) 2009 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the BSD License. 70 This document may contain material from IETF Documents or IETF 71 Contributions published or made publicly available before November 72 10, 2008. The person(s) controlling the copyright in some of this 73 material may not have granted the IETF Trust the right to allow 74 modifications of such material outside the IETF Standards Process. 75 Without obtaining an adequate license from the person(s) controlling 76 the copyright in such materials, this document may not be modified 77 outside the IETF Standards Process, and derivative works of it may 78 not be created outside the IETF Standards Process, except to format 79 it for publication as an RFC or to translate it into languages other 80 than English. 82 Table of Contents 84 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 85 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 86 3. Key Delivery Architecture . . . . . . . . . . . . . . . . . . 5 87 4. Key Distribution Exchange (KDE) . . . . . . . . . . . . . . . 6 88 4.1. Context and Scope for Distributed Keys . . . . . . . . . . 7 89 4.2. Key Distribution Exchange Scenarios . . . . . . . . . . . 8 90 5. KDE used in the EAP Re-authentication Protocol (ERP) . . . . . 8 91 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 92 6.1. Requirements on AAA Key Transport Protocols . . . . . . . 9 93 6.2. Distributing RK without Peer Consent . . . . . . . . . . . 10 94 7. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 10 95 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 96 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 98 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 99 10.2. Informative references . . . . . . . . . . . . . . . . . . 11 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 102 1. Introduction 104 The Extensible Authentication Protocol (EAP) [RFC3748] is an 105 authentication framework supporting authentication methods that are 106 specified in EAP methods. By definition, any key-generating EAP 107 method derives a Master Session Key (MSK) and an Extended Master 108 Session Key (EMSK). [RFC5295] reserves the EMSK for the sole purpose 109 of deriving root keys that can be used for specific purposes called 110 usages. In particular, [RFC5295] defines how to create a usage- 111 specific root key (USRK) for bootstrapping security in a specific 112 application, a domain-specific root key (DSRK) for bootstrapping 113 security of a set of services within a domain, and a usage-specific 114 DSRK (DSUSRK) for a specific application within a domain. [RFC5296] 115 defines a re-authentication root key (rRK) that is a USRK designated 116 for re-authentication. 118 The MSK and EMSK may be used to derive further keying material for a 119 variety of security mechanisms [RFC5247]. For example, the MSK has 120 been widely used for bootstrapping the wireless link security 121 associations between the peer and the network attachment points. 122 However, performance as well as security issues arise when using the 123 MSK and the current bootstrapping methods in mobile scenarios that 124 require handovers, as described in [RFC5169]. To address handover 125 latencies and other shortcomings, [RFC5296] specifies an EAP re- 126 authentication protocol (ERP) that uses keys derived from the EMSK or 127 DSRK to enable efficient re-authentications in handover scenarios. 128 [RFC5295] and [RFC5296] both do not specify how root keys are 129 delivered to the network server requiring the key. Such a key 130 delivery mechanism is essential because the EMSK cannot leave the EAP 131 server ([RFC5295]) but root keys are needed by other network servers 132 disjoint with the EAP server. For example, in order to enable an EAP 133 peer to re-authenticate to a network during a handover, certain root 134 keys need to be made available by the EAP server to the server 135 carrying out the re-authentication. 137 This document specifies an abstract mechanism for the delivery of the 138 EMSK child keys from the server holding the EMSK or a root key to 139 another network server that requests a root key for providing 140 protected services (such as re-authentication and other usage and 141 domain-specific services) to EAP peers. In the remainder of this 142 document, a server delivering root keys is referred to as Key 143 Delivering Server (KDS) and a server authorized to request and 144 receive root keys from a KDS is referred to as Key Requesting Server 145 (KRS). The Key Distribution Exchange (KDE) mechanism defined in this 146 document runs over an AAA (Authentication, Authorization and 147 Accounting) protocol, e.g., RADIUS [RFC2865], [RFC3579] or Diameter 148 [RFC3588], and has several variants depending on the type of key that 149 is requested and delivered (i.e., DRSK, USRK, and DSUSRK). The 150 presented KDE mechanism is a protocol template that must be 151 instantiated for a particular protocol, such as RADIUS or Diameter, 152 to specify the format and encoding of the abstract protocol messages. 153 Only after such an instantiation can the KDE mechanism described in 154 this document be implemented. The document also describes security 155 requirements for the secure key delivery over AAA. 157 2. Terminology 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC2119]. 163 AAA 164 Authentication, Authorization and Accounting. AAA protocols with 165 EAP support include RADIUS [RFC2865], [RFC3579] and Diameter 166 [RFC3588]. 168 USRK 169 Usage-Specific Root Key. A root key that is derived from the EMSK, 170 see [RFC5295]. 172 USR-KH 173 USRK Holder. A network server that is authorized to request and 174 receive a USRK from the EAP server. The USR-KH can be an AAA 175 server or dedicated service server. 177 DSRK 178 Domain-Specific Root Key. A root key that is derived from the 179 EMSK, see [RFC5295]. 181 DSR-KH 182 DSRK Holder. A network server that is authorized to request and 183 receive a DSRK from the EAP server. The most likely 184 implementation of a DSR-KH is an AAA server in a domain, enforcing 185 the policies for the usage of the DSRK within this domain. 187 DSUSRK 188 Domain-Specific Usage-Specific Root Key. A root key that is 189 derived from the DSRK, see [RFC5295]. 191 DSUSR-KH 192 DSUSRK holder. A network server authorized to request and receive 193 a DSUSRK from the DSR-KH. The most likely implementation of a 194 DSUSR-KH is an AAA server in a domain, responsible for a 195 particular service offered within this domain. 197 RK 198 Root Key. An EMSK child key, i.e., a USRK, DSRK, or DSUSRK. 200 KDS 201 Key Delivering Server. A network server that holds an EMSK or 202 DSRK and delivers root keys to KRS requesting root keys. The EAP 203 server together with the AAA server it exports the keys to for 204 delivery and the DSR-KH can both act as KDS. 206 KRS 207 Key Requesting Server. A network server that shares an interface 208 with a KDS and is authorized to request root keys from the KDS. 209 USR-KH, DSR-KH, and DSUSR-KH can all act as KRS. 211 3. Key Delivery Architecture 213 An EAP server carries out normal EAP authentications with EAP peers 214 but is typically not involved in potential handovers and re- 215 authentication attempts by the same EAP peer. Other servers are 216 typically in place to offer these requested services. These servers 217 can be AAA servers or other service network servers. Whenever EAP- 218 based keying material is used to protect a requested service, the 219 respective keying material has to be available to the server 220 providing the requested service. For example, the first time a peer 221 requests a service from a network server, this server acts as a KRS. 222 The KRS requests the root keys needed to derive the keys for 223 protecting the requested service from the respective KDS. In 224 subsequent requests from the same peer and as long as the root key 225 has not expired, the KRS can use the same root keys to derive fresh 226 keying material to protect the requested service. These kinds of key 227 requests and distributions are necessary because an EMSK cannot leave 228 the EAP server ([RFC5295]). Hence, any root key that is directly 229 derived from an EMSK can only be derived by the EAP server itself. 230 The EAP server then exports these keys to a server that can 231 distribute the keys to the KRS. In the remainder of this document, 232 the KDS consisting of the EAP server that derives the root keys 233 together with the AAA server that distributes these keys is denoted 234 EAP/AAA server. Root keys derived from EMSK child keys, such as a 235 DSUSRK, can be requested from the respective root key holder. Hence, 236 a KDS can be either the EAP/AAA server or a DSRK holder (DSR-KH), 237 whereas a KRS can be either a USRK holder (USR-KH), a DSR-KH or a 238 DSUSRK holder (DSUSR-KH). 240 The KRS needs to share an interface with the KDS to be able to send 241 all necessary input data to derive the requested key and to receive 242 the requested key. The provided data includes the Key Derivation 243 Function (KDF) that should be used to derive the requested key. The 244 KRS uses the received root key to derive further keying material in 245 order to secure its offered services. Every KDS is responsible for 246 storing and protecting the received root key as well as the 247 derivation and distribution of any child key derived from the root 248 key. An example of a key delivery architecture is illustrated in 249 Figure 1 showing the different types of KRS and their interfaces to 250 the KDS. 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | EAP/AAA server | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 / | | \ 256 / | | \ 257 / | | \ 258 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 259 | USR-KH1 | | USR-KH2 | | DSR-KH1 | | DSR-KH2 | 260 | HOKEY server| | XYZ server| |Domain 1 | | Domain 2| 261 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ 262 / | 263 / | 264 / | 265 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 266 | DSUSR-KH | | DSUSR-KH2 | 267 | Domain 1 | | Domain 2 | 268 |Home domain | |Visited domain | 269 |HOKEY server | |HOKEY server | 270 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 272 Figure 1: Example Key Delivery Architecture for the Different KRS and 273 KDS 275 4. Key Distribution Exchange (KDE) 277 In this section, a generic mechanism for a key distribution exchange 278 (KDE) over AAA is described in which a root key (RK) is distributed 279 from a KDS to a KRS. It is required that the communication path 280 between the KDS and the KRS is protected by the use of an appropriate 281 AAA transport security mechanism (see Section 6 for security 282 requirements). Here, it is assumed that the KRS and the KDS are 283 separate entities, logically if not physically, and the delivery of 284 the requested RK is specified accordingly. 286 The key distribution exchange consists of one round-trip, i.e., two 287 messages between the KRS and the KDS, as illustrated in Figure 2. 288 First, the KRS sends a KDE-Request carrying a Key Request Token 289 (KRT). As a response, the KDS sends a KDE-Response carrying a Key 290 Delivery Token (KDT). Both tokens are encapsulated in AAA messages. 291 The definition of the AAA attributes depends on the implemented AAA 292 protocol and is out of scope of this document. However, the security 293 requirements for AAA messages carrying KDE messages are discussed in 294 Section 6. The contents of KRT and KDT are defined in the following. 296 KRS KDS 297 -------- ------- 298 | | 299 | KDE-Request: AAA{KRT} | 300 |----------------------------------------->| 301 | KDE-Response: AAA{KDT} | 302 |<-----------------------------------------| 304 Figure 2: KDE Message Flow 306 KRT : (PID, KT, KL) 308 KRT carries the identifiers of the peer (PID), the key type (KT) 309 and the key label (KL). The key type specifies which type of root 310 key is requested, e.g., DSRK, USRK and DSUSRK. The encoding rules 311 for each key type are left to the protocol developers who define 312 the instantiation of the KDE mechanism for a particular protocol. 313 For the specification of key labels and the associated IANA 314 registries, please refer to [RFC5295] which specifies key labels 315 for USRKs and establishes an IANA registry for them. The same 316 specifications can be applied to other root keys. 318 KDT : (KT, KL, RK, KN_RK, LT_RK) 320 KDT carries the root key (RK) to be distributed to the KRS, as 321 well as the key type (KT) of the key, the key label (KL), the key 322 name (KN_RK) and the lifetime of RK (LT_RK). The key lifetime of 323 each distributed key MUST NOT be greater than that of its parent 324 key. 326 4.1. Context and Scope for Distributed Keys 328 The key context of each distributed key is determined by the sequence 329 of KTs in the key hierarchy. The key scope of each distributed key 330 is determined by the sequence of (PID, KT, KL)-tuples in the key 331 hierarchy and the identifier of the KRS. The KDF used to generate 332 the requested keys includes context and scope information, thus, 333 binding the key to the specific channel [RFC5295]. 335 4.2. Key Distribution Exchange Scenarios 337 Given the three types of KRS, there are three scenarios for the 338 distribution of the EMSK child keys. For all scenarios, the trigger 339 and mechanism for key delivery may involve a specific request from an 340 EAP peer and/or another intermediary (such as an authenticator). For 341 simplicity, it is assumed that USR-KHs reside in the same domain as 342 the EAP server. 344 Scenario 1: EAP/AAA server to USR-KH: In this scenario, the EAP/AAA 345 server delivers a USRK to a USR-KH. 347 Scenario 2: EAP/AAA server to DSR-KH: In this scenario, the EAP/AAA 348 server delivers a DSRK to a DSR-KH. 350 Scenario 3: DSR-KH to DSUSR-KH: In this scenario, a DSR-KH in a 351 specific domain delivers keying material to a DSUSR-KH in the same 352 domain. 354 The key distribution exchanges for Scenario 3 can be combined with 355 the key distribution exchanges for Scenario 2 into a single round- 356 trip exchange as shown in Figure 3. Here, KDE-Request and KDE- 357 Response are messages for Scenarios 2, whereas KDE-Request' and KDE- 358 Response' are messages for Scenarios 3. 360 DSUSR-KH DSR-KH EAP/AAA Server 361 -------- ------ ------------ 362 | KDE-Request'(KRT') | KDE-Request(KRT) | 363 |------------------------>|-------------------------->| 364 | KDE-Response'(KDT') | KDE-Response(KDT) | 365 |<----------------------- |<--------------------------| 366 | | | 368 Figure 3: Combined Message Exchange 370 5. KDE used in the EAP Re-authentication Protocol (ERP) 372 This section describes how the presented KDE mechanism should be used 373 to request and deliver the root keys used for re-authentication in 374 the EAP Re-authentication Protocol (ERP) defined in [RFC5296]. ERP 375 supports two forms of bootstrapping, implicit as well as explicit 376 bootstrapping, and KDE is discussed for both cases in the remainder 377 of this section. 379 In implicit bootstrapping the local EAP Re-authentication (ER) server 380 requests the DSRK from the home AAA server during the initial EAP 381 exchange. Here, the local ER server acts as the KRS and the home AAA 382 server as the KDS. In this case, the local ER server requesting the 383 DSRK includes a KDE-Request in the first EAP-Response message from 384 the peer. Here, an AAA User-Name attribute is used as the PID. If 385 the EAP exchange is successful, the home AAA server includes a KDE- 386 Response in the AAA message that carries the EAP-Success message. 388 Explicit bootstrapping is initiated by peers that do not know the 389 domain. Here, EAP-Initiate and EAP-Finish messages are exchanged 390 between the peer and the home AAA server, with the bootstrapping flag 391 in the EAP-Initiate message set. In this case, the local ER server 392 (acting as KRS) includes a KDE-Request in the AAA message that 393 carries an EAP-Initiate message with the bootstrapping flag turned 394 on. Here, an AAA User-Name attribute is used as the PID. In its 395 response, the home AAA server (acting as KDS) includes a KDE-Response 396 in the AAA message that carries the EAP-Finish message with the 397 bootstrapping flag set. 399 6. Security Considerations 401 This section provides security requirements and an analysis on 402 transporting EAP keying material using an AAA protocol. 404 6.1. Requirements on AAA Key Transport Protocols 406 Any KDE attribute that is exchanged as part of a KDE-Request or KDE- 407 Response MUST be integrity-protected and replay-protected by the 408 underlying AAA protocol that is used to encapsulate the attributes. 409 Additionally, a secure key wrap algorithm MUST be used by the AAA 410 protocol to protect the RK in a KDE-Response. Other confidential 411 information as part of the KDE messages (e.g., identifiers if privacy 412 is a requirement) SHOULD be encrypted by the underlying AAA protocol. 414 When there is an intermediary, such as an AAA proxy, on the path 415 between the KRS and the KDS, there will be a series of hop-by-hop 416 security associations along the path. The use of hop-by-hop security 417 associations implies that the intermediary on each hop can access the 418 distributed keying material. Hence the use of hop-by-hop security 419 SHOULD be limited to an environment where an intermediary is trusted 420 not to abuse the distributed key material. If such a trusted AAA 421 infrastructure does not exist, other means must be applied at a 422 different layer to ensure the end-to-end security (i.e., between KRS 423 and KDS) of the exchanged KDE messages. The security requirements 424 for such a protocol are the same as previously outlined for AAA 425 protocols and MUST hold when encapsulated in AAA messages. 427 6.2. Distributing RK without Peer Consent 429 When a KDE-Request is sent as a result of explicit ERP bootstrapping 430 [RFC5296], cryptographic verification of peer consent on distributing 431 an RK is provided by the integrity checksum of the EAP-Initiate 432 message with the bootstrapping flag turned on. 434 On the other hand, when a KDE-Request is sent as a result of implicit 435 ERP bootstrapping [RFC5296], cryptographic verification of peer 436 consent on distributing an RK is not provided. A peer is not 437 involved in the process and, thus, not aware of a key delivery 438 requests for root keys derived from its established EAP keying 439 material. Hence, a peer has no control where keys derived from its 440 established EAP keying material are distributed to. A possible 441 consequence of this is that a KRS may request and obtain an RK from 442 the home server even if the peer does not support ERP. EAP-Initiate/ 443 Re-auth-Start messages send to the peer will be silently dropped by 444 the peer causing further waste of resources. 446 7. IANA consideration 448 This document contains no IANA considerations. 450 8. Acknowledgments 452 The editors would like to thank Dan Harkins, Chunqiang Li, Rafael 453 Marin Lopez and Charles Clancy for their valuable comments. 455 9. Contributors 457 The following people contributed to this document: Kedar Gaonkar, 458 Lakshminath Dondeti, Vidya Narayanan, and Glen Zorn. 460 10. References 462 10.1. Normative References 464 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 465 Requirement Levels", BCP 14, RFC 2119, March 1997. 467 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 468 Levkowetz, "Extensible Authentication Protocol (EAP)", 469 RFC 3748, June 2004. 471 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 472 "Specification for the Derivation of Root Keys from an 473 Extended Master Session Key (EMSK)", RFC 5295, 474 August 2008. 476 [RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- 477 authentication Protocol (ERP)", RFC 5296, August 2008. 479 10.2. Informative references 481 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 482 "Remote Authentication Dial In User Service (RADIUS)", 483 RFC 2865, June 2000. 485 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 486 Dial In User Service) Support For Extensible 487 Authentication Protocol (EAP)", RFC 3579, September 2003. 489 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 490 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 492 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 493 Authentication Protocol (EAP) Key Management Framework", 494 RFC 5247, August 2008. 496 [RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti, 497 "Handover Key Management and Re-Authentication Problem 498 Statement", RFC 5169, March 2008. 500 Authors' Addresses 502 Katrin Hoeper (editor) 503 Motorola, Inc. 504 1301 E Algonquin Road 505 Schaumburg, IL 60196 506 USA 508 Phone: +1 847 576 4714 509 Email: khoeper@motorola.com 510 Yoshihiro Ohba (editor) 511 Toshiba America Research, Inc. 512 1 Telcordia Drive 513 Piscataway, NJ 08854 514 USA 516 Phone: +1 732 699 5305 517 Email: yohba@tari.toshiba.com 519 Madjid F Nakhjiri 520 Motorola, Inc. 521 6450 Sequence Drive 522 San Diego, CA 92121 523 USA 525 Phone: +1 858 404-3307 526 Email: madjid.nakhjiri@motorola.com