idnits 2.17.1 draft-ietf-dime-ikev2-psk-diameter-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5778]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, 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 (August 30, 2010) is 4982 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) == Missing Reference: 'RFC 5778' is mentioned on line 26, but not defined == Outdated reference: A later version (-14) exists of draft-ietf-dime-local-keytran-01 ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Cakulev 3 Internet-Draft Alcatel Lucent 4 Intended status: Standards Track A. Lior 5 Expires: March 3, 2011 Bridgewater Systems 6 August 30, 2010 8 Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server to 9 Diameter Server Interaction 10 draft-ietf-dime-ikev2-psk-diameter-03.txt 12 Abstract 14 The Internet Key Exchange protocol version 2 (IKEv2) is a component 15 of the IPsec architecture and is used to perform mutual 16 authentication as well as to establish and to maintain IPsec security 17 associations (SAs) between the respective parties. IKEv2 supports 18 several different authentication mechanisms, such as the Extensible 19 Authentication Protocol (EAP), certificates, and pre-shared secrets. 21 With [RFC 5778] the Diameter interworking for Mobile IPv6 between the 22 Home Agent, as a Diameter client, and the Diameter server has been 23 specified. However, that specification focused on the usage of EAP 24 and did not include support for pre-shared secret based 25 authentication available with IKEv2. This document therefore extends 26 the functionality offered by [RFC 5778] with pre-shared key based 27 authentication offered by IKEv2 when no EAP is used. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on March 3, 2011. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 5 77 3. Application Identifier . . . . . . . . . . . . . . . . . . . . 6 78 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 7 79 4.1. Support for IKEv2 and Pre-Shared Secrets . . . . . . . . . 7 80 4.2. Session Management . . . . . . . . . . . . . . . . . . . . 7 81 4.2.1. Session-Termination-Request/Answer . . . . . . . . . . 8 82 4.2.2. Abort-Session-Request/Answer . . . . . . . . . . . . . 8 83 5. Command Codes for Diameter IKEv2 with PSK . . . . . . . . . . 9 84 5.1. IKEv2-PSK-Request (IKEPSKR) Command . . . . . . . . . . . 9 85 5.2. IKEv2-PSK-Answer (IKEPSKA) Command . . . . . . . . . . . . 10 86 6. Attribute Value Pair Definitions . . . . . . . . . . . . . . . 11 87 6.1. IKEv2-Nonces . . . . . . . . . . . . . . . . . . . . . . . 11 88 6.1.1. Ni . . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 6.1.2. Nr . . . . . . . . . . . . . . . . . . . . . . . . . . 11 90 7. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . 12 91 8. AVP Flag Rules . . . . . . . . . . . . . . . . . . . . . . . . 13 92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 93 9.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . 14 94 9.2. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 14 95 9.3. AVP Values . . . . . . . . . . . . . . . . . . . . . . . . 14 96 9.4. Application Identifier . . . . . . . . . . . . . . . . . . 14 97 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 98 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 99 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 100 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 103 1. Introduction 105 [RFC4306] defines the version 2 of Internet Key Exchange (IKE) as a 106 protocol that performs mutual authentication between two parties and 107 establishes a security association (SA) that includes shared secret 108 information that can be used to efficiently establish SAs for 109 Encapsulating Security Payload (ESP) [RFC4303] and/or Authentication 110 Header (AH) [RFC4302], and a set of cryptographic algorithms to be 111 used by the SAs to protect the traffic that they carry. IKEv2 112 protocol allows several different mechanisms for authenticating a 113 IKEv2 Peer to be used, such as the Extensible Authentication 114 Protocol, certificates, and pre-shared secrets. 116 From a service provider perspective, it is important to ensure that a 117 user is authorized to use the services. Therefore, the IKEv2 Server 118 must verify that the IKEv2 Peer is authorized for the requested 119 services possibly with the assistance of the operator's Diameter 120 servers. [RFC5778] defines the home agent as a Diameter client to 121 the Diameter server communication when the mobile node authenticates 122 using the IKEv2 protocol with the Extensible Authentication Protocol 123 (EAP) [RFC3748] or using the Mobile IPv6 Authentication Protocol 124 [RFC4285]. This document extends the functionality offered by 125 [RFC5778] with pre-shared key based authentication offered by IKEv2. 126 This document does not assume that the IKEv2 Server has the pre- 127 shared secrets (PSK) with the IKEv2 Peer. Instead, it allows for PSK 128 to be derived for a specific IKEv2 session and exchanged between 129 IKEv2 Server and HAAA. This is accomplished through the use of a new 130 Diameter application specifically designed for performing IKEv2 131 authorization decisions. 133 2. Requirements notation 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119]. 139 3. Application Identifier 141 This specification defines a new Diameter application and its 142 respective Application Identifier: 144 Diameter IKE PSK (IKEPSK) TBD1 by IANA 146 The IKEPSK Application Identifier is used when the IKEv2 Peer is to 147 be authenticated and authorized using IKEv2 with PSK-based 148 authentication. 150 4. Protocol Description 152 4.1. Support for IKEv2 and Pre-Shared Secrets 154 When IKEv2 is used with PSK-based initiator authentication, the 155 Diameter commands IKEv2-PSK-Request/Answer defined in this document 156 are used between IKEv2 server and a Home AAA server (HAAA) to 157 authorize the IKEv2 Peer for the services. Upon receiving the 158 IKE_AUTH message from the IKEv2 Peer, the IKEv2 Server uses the 159 information received in IDi to determine if it has the PSK for this 160 IKEv2 Peer. If there is no PSK found associated with this IKEv2 161 Peer, the IKEv2 Server MUST send an Authorize-Only (Auth-Request-Type 162 set to "Authorize-Only") Diameter IKEv2-PSK message with the IKEv2 163 Peer's IDi payload to the HAAA to obtain the PSK. The IDi payload 164 extracted from the IKE_AUTH message MUST contain an identity that is 165 meaningful for the Diameter infrastructure, such as a Network Access 166 Identifier (NAI), since it is used by the IKEv2 Server to populate 167 the User-Name AVP in the Diameter message. The IKEv2 Server also 168 includes in the IKEv2-Nonces AVP of the same Diameter message the 169 initiator and responder nonces (Ni and Nr) exchanged during initial 170 IKEv2 exchange. 172 This message is routed to the IKEv2 Peer's HAAA. Upon receiving 173 Diameter IKEv2-PSK-Request message from the IKEv2 Server, the HAAA 174 SHALL use the User-Name AVP to retrieve the associated keying 175 material. The HAAA SHALL use the nonces Ni and Nr received in IKEv2- 176 Nonces AVP to generate the PSK. The HAAA returns the PSK to the 177 IKEv2 Server using the Key AVP as specified in 178 [I-D.ietf-dime-local-keytran]. It is outside of scope of this 179 document how the HAAA obtains or generates the PSK. For example, if 180 the HAAA previously performed EAP based access authentication and 181 authorization of the IKEv2 Peer, it can use the available EMSK to 182 generate the PSK [RFC5295]. 184 Once the IKEv2 Server receives the PSK from the HAAA, the IKEv2 185 Server verifies the IKE_AUTH message received from the IKEv2 Peer. 186 If the verification of AUTH is successful, the IKEv2 Server sends the 187 IKE message back to the IKEv2 Peer. 189 4.2. Session Management 191 The HAAA may maintain state or may be stateless. This is indicated 192 by presence or absence of the Auth-Session-State AVP. The IKEv2 193 Server MUST support the Authorization Session State Machine defined 194 in [RFC3588]. 196 This specification makes an assumption that each IKE_SA created 197 between the IKEv2 Peer and the IKEv2 Server as a result of a 198 successful IKEv2 negotiation exchange together with CHILD_SAs set up 199 through that particular IKE_SA correspond to one currently active PSK 200 and one active Diameter session. 202 4.2.1. Session-Termination-Request/Answer 204 In the case where session tracking is being used, when the IKEv2 205 Server terminates the SA it SHALL send a Session-Termination-Request 206 (STR) message [RFC3588] to inform the HAAA that the authorized 207 session has been terminated. 209 The Session-Termination-Answer (STA) message [RFC3588] is sent by the 210 HAAA to acknowledge the notification that the session has been 211 terminated. 213 4.2.2. Abort-Session-Request/Answer 215 The Abort-Session-Request (ASR) message [RFC3588] is sent by the HAAA 216 to the IKEv2 Server to terminate the authorized session. When the 217 IKEv2 Server receives the ASR message, it MUST delete the 218 corresponding IKE_SA and all CHILD_SAs set up through it. 220 The Abort-Session-Answer (ASA) message [RFC3588] is sent by the IKEv2 221 Server in response to an ASR message. 223 5. Command Codes for Diameter IKEv2 with PSK 225 This section defines new Command-Code values that MUST be supported 226 by all Diameter implementations conforming to this specification. 228 +-------------------+---------+------+-------------+-------------+ 229 | Command-Name | Abbrev. | Code | Reference | Application | 230 +-------------------+---------+------+-------------+-------------+ 231 | IKEv2-PSK-Request | IKEPSKR | TBD2 | Section 5.1 | IKEPSK | 232 | | | | | | 233 | IKEv2-PSK-Answer | IKEPSKA | TBD3 | Section 5.2 | IKEPSK | 234 +-------------------+---------+------+-------------+-------------+ 236 Table 1: Command Codes 238 5.1. IKEv2-PSK-Request (IKEPSKR) Command 240 The IKEv2-PSK-Request message, indicated with the Command-Code set to 241 TBD2 and the 'R' bit set in the Command Flags field is sent from the 242 IKEv2 Server to the HAAA to initiate IKEv2 with PSK authorization. 243 In this case, the Application-ID field of the Diameter Header MUST be 244 set to the Diameter IKE PSK Application ID (value of TDB1). 246 Message format 248 ::= < Diameter Header: TBD2, REQ, PXY > 249 < Session-Id > 250 { Auth-Application-Id } 251 { Origin-Host } 252 { Origin-Realm } 253 { Destination-Realm } 254 { Auth-Request-Type } 255 [ Destination-Host ] 256 [ NAS-Identifier ] 257 [ NAS-IP-Address ] 258 [ NAS-IPv6-Address ] 259 [ NAS-Port ] 260 [ Origin-State-Id ] 261 { User-Name } 262 [ Key ] 263 [ Auth-Session-State ] 264 { IKEv2-Nonces } 265 * [ Proxy-Info ] 266 * [ Route-Record ] 267 ... 268 * [ AVP ] 270 IKEv2-PSK-Request message MUST include a IKEv2-Nonces AVP containing 271 Ni and Nr nonces exchanged during initial IKEv2 exchange. IKEv2-PSK- 272 Request message MAY contain a KEY AVP. If KEY AVP is included it 273 contains Key-SPI AVP with Security Parameter Index (SPI) to be used 274 to identify the appropriate PSK. 276 5.2. IKEv2-PSK-Answer (IKEPSKA) Command 278 The IKEv2-PSK-Answer (IKEPSKA) message, indicated by the Command-Code 279 field set to TBD3 and the 'R' bit cleared in the Command Flags field, 280 is sent by the HAAA to the IKEv2 Server in response to the IKEPSKR 281 command. In this case, the Application-ID field of the Diameter 282 Header MUST be set to the Diameter IKE PSK Application ID (value of 283 TDB1). 285 Message format 287 ::= < Diameter Header: TBD3, PXY > 288 < Session-Id > 289 { Auth-Application-Id } 290 { Auth-Request-Type } 291 { Result-Code } 292 { Origin-Host } 293 { Origin-Realm } 294 [ User-Name ] 295 [ Key ] 296 [ Error-Message ] 297 [ Error-Reporting-Host ] 298 * [ Failed-AVP ] 299 [ Origin-State-Id ] 300 * [ Redirect-Host ] 301 [ Redirect-Host-Usage ] 302 [ Redirect-Max-Cache-Time ] 303 * [ Proxy-Info ] 304 * [ Route-Record ] 305 ... 306 * [ AVP ] 308 If the authorization procedure was successful then the IKEv2-PSK- 309 Answer message SHALL include the Key AVP as specified in 310 [I-D.ietf-dime-local-keytran]. The value of the Key-Type AVP SHALL 311 be set to TBD4. The Keying-Material AVP SHALL contain the PSK. 312 Exactly how the PSK is derived is beyond the scope of this document. 313 The Key-Lifetime AVP may be included and if it is included then the 314 associated key shall not be used if the lifetime has expired. 316 6. Attribute Value Pair Definitions 318 This section defines new AVPs for the IKEv2 with PSK. 320 6.1. IKEv2-Nonces 322 The IKEv2-Nonces AVP (Code TBD5) is of type Grouped and contains the 323 nonces exchanged between the IKEv2 Peer and the IKEv2 Server during 324 IKEv2 initial exchange. The nonces are used for PSK generation. 326 IKEv2-Nonces ::= < AVP Header: TBD5> 327 {Ni} 328 {Nr} 329 *[AVP] 331 6.1.1. Ni 333 The Ni AVP (AVP Code TBD6) is of type Unsigned32 and contains the 334 IKEv2 initiator nonce. 336 6.1.2. Nr 338 The Nr AVP (AVP Code TBD7) is of type Unsigned32 and contains the 339 IKEv2 responder nonce. 341 7. AVP Occurrence Tables 343 The following tables present the AVPs defined or used in this 344 document and their occurrences in Diameter messages. Note that AVPs 345 that can only be present within a Grouped AVP are not represented in 346 this table. 348 The table uses the following symbols: 350 0: 352 The AVP MUST NOT be present in the message. 354 0+: 356 Zero or more instances of the AVP MAY be present in the message. 358 0-1: 360 Zero or one instance of the AVP MAY be present in the message. 362 1: 364 One instance of the AVP MUST be present in the message. 366 +-------------------+ 367 | Command-Code | 368 |---------+---------+ 369 AVP Name | IKEPSKR | IKEPSKA | 370 -------------------------------|---------+---------+ 371 Key | 0-1 | 0-1 | 372 IKEv2-Nonces | 1 | 0 | 373 +---------+---------+ 375 IKEPSKR and IKEPSKA Commands AVP Table 377 8. AVP Flag Rules 379 The following table describes the Diameter AVPs, their AVP Code 380 values, types, possible flag values, and whether the AVP MAY be 381 encrypted. The Diameter base [RFC3588] specifies the AVP Flag rules 382 for AVPs in Section 4.5. 384 +--------------------+ 385 | AVP Flag rules | 386 +----+---+------+----+----+ 387 AVP Defined | | |SHOULD|MUST|MAY | 388 Attribute Name Code in Value Type |MUST|MAY| NOT | NOT|Encr| 389 +-------------------------------------------+----+---+------+----+----+ 390 |Key TBD Note 1 Grouped | M | P | | V | Y | 391 +-------------------------------------------+----+---+------+----+----+ 392 |Keying-Material TBD Note 1 OctetString| M | P | | V | Y | 393 +-------------------------------------------+----+---+------+----+----+ 394 |Key-Lifetime TBD Note 1 Integer64 | M | P | | V | Y | 395 +-------------------------------------------+----+---+------+----+----+ 396 |Key-SPI TBD Note 1 Unsigned32 | M | P | | V | Y | 397 +-------------------------------------------+----+---+------+----+----+ 398 |Key-Type TBD Note 1 Enumerated | M | P | | V | Y | 399 +-------------------------------------------+----+---+------+----+----+ 400 |Key-Name TBD Note 1 OctetString| M | P | | V | Y | 401 +-------------------------------------------+----+---+------+----+----+ 402 |IKEv2-Nonces TBD5 6.2 Grouped | M | P | | V | Y | 403 +-------------------------------------------+----+---+------+----+----+ 404 |Ni TBD6 6.2.1 Unsigned32 | M | P | | V | Y | 405 +-------------------------------------------+----+---+------+----+----+ 406 |Nr TBD7 6.2.2 Unsigned32 | M | P | | V | Y | 407 +-------------------------------------------+----+---+------+----+----+ 409 AVP Flag Rules Table 411 Note 1: Key, Keying-Material, Key-Type, Key-SPI, Key-Name and Key- 412 Lifetime AVPs are defined in [I-D.ietf-dime-local-keytran]. 414 9. IANA Considerations 416 This section contains the namespaces that have either been created in 417 this specification or had their values assigned to existing 418 namespaces managed by IANA. 420 9.1. Command Codes 422 IANA is requested to allocate a command code value for the IKEv2-PSK- 423 Request message (IKEPSKR) and for the IKEv2-PSK-Answer message 424 (IKEPSKA) from the Command Code namespace defined in [RFC3588]. See 425 Section 5 for the assignment of the namespace in this specification. 427 9.2. AVP Codes 429 This specification requires IANA to register the following new AVPs 430 from the AVP Code namespace defined in [RFC3588]. 432 o IKEv2-Nonces 434 o Ni 436 o Nr 438 The AVPs are defined in Section 6. 440 9.3. AVP Values 442 IANA is requested to create a new value for the Key-Type AVP. The 443 new value TBD4 signifies that IKEv2 PSK is being sent. 445 9.4. Application Identifier 447 This specification requires IANA to allocate one new value "Diameter 448 IKE PSK" from the Application Identifier namespace defined in 449 [RFC3588]. 451 Application Identifier | Value 452 -------------------------------+------ 453 Diameter IKE PSK (IKEPSK) | TBD1 455 10. Security Considerations 457 The security considerations of the Diameter Base protocol [RFC3588] 458 are applicable to this document. 460 The Diameter messages between the IKEv2 Server and the HAAA may be 461 transported via one or more AAA brokers or Diameter agents. In this 462 case, the HA to the Diameter server AAA communication relies on the 463 security properties of the intermediating AAA inter-connection 464 networks, AAA brokers, and Diameter agents. Furthermore, any agents 465 that process IKEv2-PSK-Answer messages can see the contents of the 466 Key AVP. For this reason, this specification strongly recommends 467 avoiding Diameter agents when they cannot be trusted to keep the keys 468 secret. 470 This specification expects that the HAAA derives and returns the 471 associated session key to the IKEv2 Server. For the key derivation 472 this specification recommends the use of a short lived secrets, 473 possibly based on a previous network access authentication run if 474 such secrets are available. To ensure key freshness, limit the key 475 scope etc., this specification also recommends the use of nonces, if 476 nonces are included in IKEv2-PSK-Request. However, this 477 specification does not define how the Diameter server actually 478 derives required keys. The details of the key derivation depends on 479 the deployment where this specification is used and therefore the 480 security properties of the system depend on how this is done. 482 11. References 484 11.1. Normative References 486 [I-D.ietf-dime-local-keytran] 487 Wu, W. and G. Zorn, "Diameter Attribute-Value Pairs for 488 Cryptographic Key Transport", 489 draft-ietf-dime-local-keytran-01 (work in progress), 490 January 2010. 492 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 493 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 495 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 496 December 2005. 498 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 499 RFC 4303, December 2005. 501 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 502 RFC 4306, December 2005. 504 11.2. Informative References 506 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 507 Requirement Levels", BCP 14, RFC 2119, March 1997. 509 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 510 Levkowetz, "Extensible Authentication Protocol (EAP)", 511 RFC 3748, June 2004. 513 [RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 514 Chowdhury, "Authentication Protocol for Mobile IPv6", 515 RFC 4285, January 2006. 517 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 518 "Specification for the Derivation of Root Keys from an 519 Extended Master Session Key (EMSK)", RFC 5295, 520 August 2008. 522 [RFC5778] Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G., 523 and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home 524 Agent to Diameter Server Interaction", RFC 5778, 525 February 2010. 527 Authors' Addresses 529 Violeta Cakulev 530 Alcatel Lucent 531 600 Mountain Ave. 532 3D-517 533 Murray Hill, NJ 07974 534 US 536 Phone: +1 908 582 3207 537 Email: violeta.cakulev@alcatel-lucent.com 539 Avi Lior 540 Bridgewater Systems 541 303 Terry Fox Drive 542 Otawa, Ontario K2K 3J1 543 Canada 545 Phone: +1 613-591-6655 546 Email: avi@bridgewatersystems.com