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