idnits 2.17.1 draft-calhoun-diameter-impl-guide-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 20 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 12 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 266: '...e in the network MUST know a priori ab...' RFC 2119 keyword, line 267: '...s, and each peer MAY have a relative p...' RFC 2119 keyword, line 270: '... it MUST attempt to redirect all tra...' RFC 2119 keyword, line 274: '...er proxy servers SHOULD drop all respo...' RFC 2119 keyword, line 275: '... client, and MUST respond to all req...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 590 has weird spacing: '... In the ca...' -- 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 (February 2001) is 8470 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2138 (ref. '1') (Obsoleted by RFC 2865) == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-15 == Outdated reference: A later version (-06) exists of draft-calhoun-diameter-nasreq-03 ** Obsolete normative reference: RFC 2284 (ref. '4') (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 2486 (ref. '6') (Obsoleted by RFC 4282) == Outdated reference: A later version (-13) exists of draft-ietf-sigtran-sctp-09 Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AAA Working Group Pat R. Calhoun 3 Internet-Draft Sun Microsystems, Inc. 4 Category: Informational Allan C. Rubens 5 Tut Systems, Inc. 6 Haseeb Akhtar 7 Nortel Networks 8 William Bulley 9 Merit Network, Inc. 10 Jeff Haag 11 Cisco Systems 12 February 2001 14 Diameter Implementation Guidelines 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at: 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at: 35 http://www.ietf.org/shadow.html. 37 This document is an individual contribution for consideration by the 38 AAA Working Group of the Internet Engineering Task Force. Comments 39 should be submitted to the diameter@ipass.com mailing list. 41 Distribution of this memo is unlimited. 43 Copyright (C) The Internet Society 1999. All Rights Reserved. 45 Abstract 47 The Diameter protocol is used for Authentication, Authorization and 48 Accounting (AAA) for Mobile-IP, ROAMOPS and NASREQ. This document 49 contains implementation guidelines that may be useful to Diameter 50 protocol developers. 52 Table of Contents 54 1.0 Introduction 55 2.0 Base Protocol 56 2.1 Backward Compatibility with RADIUS 57 2.2 Device-Reboot-Ind Message Flow 58 2.3 Message-Reject-Ind Message Flow 59 2.4 Peer Fail-Over and Load Balancing 60 2.5 Multiple IP Addresses 61 2.6 Maintaining Per-Request State 62 3.0 NASREQ Extension 63 3.1 RADIUS/Diameter Protocol Interactions 64 3.1.1 RADIUS request forwarded as Diameter request 65 3.1.2 Diameter request forwarded as RADIUS request 66 3.2 EAP Retransmission and Timer 67 3.3 Example of an EAP OTP Authentication 68 3.3.1 Successful Authentication 69 3.3.2 NAS Initiated EAP Authentication 70 3.3.3 Server-Initiated Authentication 71 3.3.4 Example of failed EAP Authentication 72 3.3.5 Example of Diameter Server not supporting EAP 73 3.3.6 Example of Diameter Proxy not supporting EAP 74 3.3.7 Example of PPP Client not supporting EAP 75 4.0 References 76 5.0 Acknowledgements 77 5.0 Authors' Addresses 78 6.0 Full Copyright Statement 80 1.0 Introduction 82 The Diameter protocol is used for Authentication, Authorization and 83 Accounting (AAA) for Mobile-IP, ROAMOPS and NASREQ. This document 84 contains implementation guidelines that may be useful to Diameter 85 protocol developers. 87 This specification contains implementation guidelines for both the 88 Diameter base protocol [2] and the NASREQ extension [3]. 90 2.0 Base Protocol 92 This section contains implementation guidelines for the Diameter Base 93 protocol [2]. 95 2.1 Backward Compatibility with RADIUS 97 The Diameter protocol was designed with RADIUS [1] compatibility in 98 mind. The RADIUS protocol defines a one octet attribute space, and 99 the Diameter protocol reserves the first 255 attribute identifiers to 100 be the same as those defined in RADIUS. This allows Diameter servers 101 to easily perform protocol conversion, since an additional dictionary 102 lookup would not be necessary in order to map a RADIUS attribute to a 103 Diameter AVP. 105 By re-using the RADIUS attribute space, a Diameter server could 106 easily read a typical RADIUS user profile without any additional 107 conversions. This reduces the need to create duplicate user profiles 108 for both protocols, and also does not require any database conversion 109 while reading the profiles. 111 2.2 Device-Reboot-Ind Message Flow 113 The following figure depicts a sample flow of Device-Reboot-Ind 114 between three Diameter peers, one being a proxy or broker server. In 115 this example DIA1 initiates the bootstrap sequence with DIA2, and 116 later DIA3 initiates the bootstrap sequence with DIA2. After some 117 time DIA1 needs to reboot and informs DIA2. The details of each 118 message is provided below. 120 +-------+ +-------+ +-------+ 121 | DIA1 | | PROXY | | DIA3 | 122 | | | DIA2 | | | 123 +-------+ +-------+ +-------+ 124 | | | 125 |DRI (ns=0, nr=0) | | 126 | Rebooted | | 127 | version 1, | | 128 | extensions 1, 4 | | 129 (a) |------------------->| | 130 |DRI (ns=0, nr=1) | | 131 | Rebooted | | 132 | version 1, | | 133 | extension 1 | | 134 (b) |<-------------------| | 135 |ZLB (ns=0, nr=1) | | 136 (c) |------------------->| | 137 | . |DRI (ns=0, nr=0) | 138 | . | Rebooted | 139 | | version 1, | 140 | | extensions 1, 2 | 141 (d) | |<------------------| 142 | |DRI (ns=0, nr=1) | 143 | | Rebooted | 144 | | version 1, | 145 | | extension 1 | 146 (e) | |------------------>| 147 | |ZLB (ns=0, nr=1) | 148 (f) | |<------------------| 149 |DRI (ns=x, nr=y) | . | 150 | Upcoming Reboot | . | 151 (g) |------------------->| | 152 | . | | 153 | . | | 154 |DRI (ns=0, nr=0) | | 155 | Rebooted | | 156 | version 1, | | 157 | extensions 1, 4 | | 158 (h) |------------------->| | 159 | | | 160 Figure 1: Sample DRI Message Flow in a Proxy Environment 162 (a) DIA1 sends a DRI message to DIA2 indicating that its version 163 is one (1) and that it supports extensions 1 (NASREQ) and 4 164 (Mobile-IP). 166 (b) DIA2 sends a DRI message to DIA1 indicating that its version 167 is one (1) and that it supports extension 1 (NASREQ). This 168 message also includes a piggy-backed acknowledgement of (a). 170 (c) DIA1 sends an acknowledgement of (b) 172 (d) DIA3 sends a DRI message to DIA2 indicating that its version 173 is one (1) and that it supports extension 1 (NASREQ) and 2 174 (Strong Security). 176 (e) DIA2 sends a DRI message to DIA3 indicating that its version 177 is one (1) and that it supports extension 1 (NASREQ). This 178 message also includes a piggy-backed acknowledgement of (d). 180 (f) DIA3 sends an acknowledgement of (e) 182 (g) after some time DIA1 sends an indication to DIA2 that it is 183 about to reboot. All messages destined to the realm for which 184 DIA1 is responsible for should be redirected to an alternate 185 Diameter Server. 187 (h) Once the reboot is complete, DIA sends the DRI, which causes 188 steps (a) through (c) to be repeated. 190 2.3 Message-Reject-Ind Message Flow 192 The following figure show sample flows of MRI command between two 193 Diameter peers. In this example DIA1 and DIA2 servers generates error 194 messages. The details of the messages are provided below. 196 +-------+ +-------+ 197 | DIA1 | | DIA2 | 198 +-------+ +-------+ 199 | | 200 |Unknown command | 201 (a) |------------------------------------>| 202 |MRI, err=Diameter_COMMAND_UNSUPPORTED| 203 (b) |<------------------------------------| 204 | . | 205 | . | 206 |Unknown AVP | 207 (c) |<------------------------------------| 208 |MRI, err=Diameter_AVP_UNSUPPORTED | 209 (d) |------------------------------------>| 210 | . | 211 | . | 212 |Bad value in a valid AVP | 213 (e) |------------------------------------>| 214 |MRI, err=Diameter_INVALID_AVP_VALUE | 215 (f) |<------------------------------------| 216 Figure 2: Sample MRI Message Flow 218 (a) DIA2 receives an unknown command from DIA1. 220 (b) DIA2 recognizes that it received an unknown command and hence 221 sends an MRI with the Result-Code AVP set to 222 Diameter_COMMAND_UNSUPPORTED and the Command-Code AVP 223 encapsulated within the Failed-AVP AVP. 225 (c) DIA1 receives an unknown AVP in a message sent by DIA2. 227 (d) DIA1 recognizes that it received an unknown AVP and returns an 228 MRI with the Result-Code AVP set to Diameter_AVP_UNSUPPORTED 229 and the offending AVP encapsulated within a Failed-AVP AVP. 231 (e) DIA2 receives a bad parameter within a otherwise valid AVP 232 from DIA1. 234 (f) As soon as it discovers that it has received a bad parameter, 235 it returns an MRI message to DIA1 with the Result-Code AVP set 236 to Diameter_INVALID_AVP_VALUE and the offending AVP 237 encapsulated within a Failed-AVP AVP. 239 2.4 Peer Fail-Over and Load Balancing 241 Although not a function of the Diameter protocol, in some networks it 242 is desirable to ensure resilient service by providing alternate 243 peers, should communication with a peer fail. Figure 3 provides an 244 example of such a network, where the client communicates with one of 245 two servers providing proxying services. The proxy servers, in turn, 246 communicate with one of two servers in the home administrative 247 domain. 249 +--------+ 250 | DIAM | 251 | Primary| 252 +--------+ | Home | 253 | DIAM +---------+ Server +----+ 254 | Primary| +--------+ | 255 +--------+ | Proxy | +--------+ | 256 | +--------+ Server +---------+ DIAM | | 257 | DIAM | +--------+ |Alternat| | 258 | Client | +--------+ | Home | | 259 | +--------+ DIAM +---------+ Server | | 260 +--------+ |Alternat| +--------+ | 261 | Proxy | | 262 | Server +-----------------------+ 263 +--------+ 264 Figure 3: Redundant Diameter Servers 266 Each node in the network MUST know a priori about its communicating 267 peers, and each peer MAY have a relative priority, forcing all 268 traffic to be sent through a preferred server, if it is available. 269 When a node detects that a communicating peer is no longer available, 270 it MUST attempt to redirect all traffic (including the packets in the 271 retransmission queue destined for the former peer) to the new peer. 272 It is possible that an alternate path not exist, such would be the 273 case if the Diameter Client was no longer reachable. In this case, 274 the Diameter proxy servers SHOULD drop all responses directed to the 275 client, and MUST respond to all requests directed to the client with 276 an appropriate Result Code. 278 An implementation MAY also make use of the multiple peer arrangement 279 described above to balance the load between a set of peers. A clever 280 implementation MAY also redirect traffic to an alternate peer when it 281 detects that its primary communicating peer's window is full. 283 2.5 Multiple IP Addresses 285 SCTP supports multiple IP addresses per Diameter host, and the Host- 286 Name AVP MAY resolve to more than one address. The alternate 287 addresses supplied by the host name resolution SHOULD be used to 288 determine the complete set of addresses indicated by the Host-Name 289 AVP. 291 2.6 Maintaining Per-Request State 293 Some applications of Diameter servers require that local state 294 information be maintained for each request, to assist in the 295 processing of the corresponding response. It is important to note 296 that a Diameter server that maintains per-request state information 297 introduces a single point of failure, reducing the reliability of the 298 service. There are two methods that MAY be implemented that allow 299 per-request state information to be maintained: 301 1. DIA2 MAY maintain a state control block to allow it to match a 302 response with a corresponding request. The state control block 303 MAY include AVPs that need to be added to the response, or any 304 additional policy decisions that will need to be made when the 305 response is received. 307 2. DIA2 MAY add a Proxy-State AVP (see section 6.2.1) to a 308 request, which may contain any state information that will be 309 needed when the corresponding response is received. When a 310 Diameter node adds its own Proxy-State AVP to a message that 311 already includes such an AVP, it MUST ensure that the original 312 AVP is present in the corresponding response. One suggested 313 method is to "encapsulate" the original Proxy-State AVP in the 314 new Proxy-State AVP. 316 3.0 NASREQ Extension 318 This section contains implementation guidelines for the NASREQ 319 Diameter Extension [3]. 321 3.1 RADIUS/Diameter Protocol Interactions 323 This section describes some basic guidelines that may be used by 324 servers that act as protocol gateways. Note that this document does 325 not restrict implementations from creating other methods, as long as 326 the bridging function doesn't break the RADIUS nor the Diameter 327 protocol. 329 There are essentially two different situations that must be handled; 330 one where a RADIUS request is received that must be forwarded as a 331 Diameter request, and the inverse. Note that this section uses two 332 different terms; AVP and attribute. The former is used to signify a 333 Diameter AVP, while the latter is used to signify a RADIUS attribute. 335 3.1.1 RADIUS request forwarded as Diameter request 336 This section describes the actions that should be followed when a 337 protocol Gateway receives a RADIUS message that is to be translated 338 to a Diameter message. 340 It is important to note that RADIUS servers are inherently stateless, 341 and this section maintains that assumption. It is quite possible for 342 the RADIUS messages that comprises the session (i.e. authentication 343 and accounting messages) be handled by different protocol gateways in 344 the proxy network. 346 When a protocol gateway receives a RADIUS message, the following 347 steps should be taken: 349 - The NAS-IP-Address and/or NAS-Identifier AVPs are included in 350 the Diameter request. These AVPs identify the NAS providing the 351 service to the user. 352 - The Host-Name AVP is added with the local server's identity. 353 This will ensure that the corresponding response will be 354 returned to the correct gateway server. 355 - The Gateway Server must maintain state information relevant to 356 the RADIUS request, such as the Identifier field in the RADIUS 357 header, any existing RADIUS Proxy-State attribute as well as the 358 source IP address and port number of the UDP packet. These may 359 be maintained locally in a state table, or may be saved in a 360 Proxy-State AVP. 361 - If the Acct-Session-Id attribute was found in the request, the 362 contents are inserted in the Acct-Session-Id AVP. 363 - If the RADIUS request contained a Class or State attribute, the 364 contents of the attribute contain the Diameter Session-Id. If no 365 such attributes are present, and the RADIUS command is an 366 Access-Request, a new Session-Id is created. The Session-Id is 367 included in the Session-Id AVP. 369 The corresponding Diameter response is always guaranteed to be 370 received by the same protocol gateway that translated the original 371 request, due to the contents of the Host-Name AVP in the Diameter 372 request. The following steps are applied to the response message 373 during the Diameter to RADIUS translation: 375 - If the Diameter Command-Code is set to AA-Challenge, the 376 Diameter Session Idenfitier is saved in the RADIUS State 377 attribute. This is necessary in order to ensure that the 378 protocol gateway that will receive the subsequent RADIUS 379 Access-Request will have access to the Session Identifier. 380 - If the Command-Code is set to AA-Answer, the Diameter Session 381 Identifier is saved in a new RADIUS Class attribute, whose 382 format consists of the string "Diameter/" followed by the 383 Diameter Session Identifier. This will ensure that the 384 subsequent Accounting messages, which could be received by any 385 protocol gateway, would have access to the original Diameter 386 Session Identifier. 387 - If a Proxy-State attribute was present in the RADIUS request, 388 the same attribute is added in the response. This information 389 may be found in the Proxy-State AVP, or in a local state table. 390 - If state information regarding the RADIUS request was saved in a 391 Proxy-State AVP, the RADIUS Identifier and UDP IP Address and 392 port number are extracted and used in issuing the RADIUS reply. 394 3.1.2 Diameter request forwarded as RADIUS request 396 When a server receives a Diameter request that is to be forwarded to 397 a RADIUS entity, the following steps are an example of the steps that 398 may be followed: 400 - The Host-Name AVP's value is inserted in the NAS-Identifier 401 attribute. Since the contents of the Host-Name AVP is in an NAI 402 [6] format, and the NAS-Idenfitier follows the Fully Qualified 403 Domain Name (FQDN) syntax rules, the NAI's realm delimited '@' 404 must be replaced by a dot '.'. 405 - The Host-Name and Session Identifier must be retained in order 406 to ensure that the information is present in the corresponding 407 response. The gateway server may keep this information in a 408 local state table, or may add the information in a RADIUS 409 Proxy-State attribute. 411 When the corresponding response is received by the gateway server, 412 which is guaranteed in the RADIUS protocol, the following steps may 413 be followed: 415 - If a Proxy-State AVP is present, extract the Host-Name and 416 Session Identifier information, otherwise find the information 417 in a local state table. 418 - The Host-Name information is added to the Destination-NAI AVP. 419 - The Session-Id information is added to the Session-Id AVP. 420 - If the RADIUS Class or State attributes are present, these 421 attributes must be present in the Diameter response. 423 3.2 EAP Retransmission and Timers 425 As noted in [4], the EAP authenticator (NAS) is responsible for 426 retransmission of packets between the authenticating peer (PPP 427 client) and the NAS. Thus if an EAP packet is lost in transit between 428 the authenticating peer and the NAS (or vice versa), the NAS will 429 retransmit. Since Diameter operates over SCTP [7], which provides 430 reliability, all EAP packets sent to a Diameter peer will be 431 retransmitted automatically. 433 Note that it may be necessary to adjust authentication timeouts in 434 certain cases. For example, when a token card is used additional time 435 may be required to allow the user to find the card and enter the 436 token. Since the NAS will typically not have knowledge of the 437 required parameters, these need to be provided by the Diameter 438 server. This can be accomplished by inclusion of the Idle-Timeout in 439 the Diameter-EAP-Answer message. 441 3.3 Example of an EAP OTP Authentication 443 This section provides sample messages exchanges between an 444 Authenticating Peer, which is typically a dial-up PPP client, a NAS 445 and a Diameter server. The protocol used between the Dial-up PPP 446 client and the NAS is EAP over PPP as defined in [4]. The protocol 447 between the NAS and the Diameter Server is EAP encapsulated within 448 Diameter, as described in this specification. 450 For all PPP packets, the messages are formatted as: 451 [LCP Packet Type] 452 [EAP Packet Type]/[EAP Payload] 454 For all Diameter packets, the messages are formatted as: 455 [Diameter Command Code]/[EAP Packet Type]/[EAP Payload] 457 In the example provided below, the PPP client attempts to 458 authenticate using a One-Time-Password [5] encapsulated within EAP 459 [4]. 461 3.3.1 Successful Authentication 463 The example below shows the conversation between the authenticating 464 peer, NAS, and server, for the case of a One Time Password (OTP) 465 authentication. OTP is used only for illustrative purposes; other 466 authentication protocols could also have been used, although they 467 would show somewhat different behavior. 469 Authenticating Peer NAS Diameter Server 470 ------------------- --- --------------- 472 <- PPP LCP Request-EAP 473 auth 474 PPP LCP ACK-EAP 475 auth -> 476 Diameter- 477 EAP-Request/ 478 EAP-Payload/Start -> 479 <- Diameter- 480 EAP-Answer/ 481 EAP- 482 Payload/Identity 483 <- PPP EAP-Request/ 484 Identity 485 PPP EAP-Response/ 486 Identity (MyID) -> 487 Diameter- 488 EAP-Request/ 489 EAP-Payload/ 490 EAP-Response/ 491 (MyID) -> 492 <- Diameter- 493 EAP-Answer/ 494 EAP-Payload/EAP- 495 Request 496 OTP/OTP Challenge 497 <- PPP EAP-Request/ 498 OTP/OTP Challenge 499 PPP EAP-Response/ 500 OTP, OTPpw -> 501 Diameter- 502 EAP-Request/ 503 EAP-Payload/ 504 EAP-Response/ 505 OTP, OTPpw -> 506 <- Diameter- 507 EAP-Answer/ 508 EAP-Payload/EAP- 509 Success 510 (other AVPs) 511 <- PPP EAP-Success 512 PPP Authentication 513 Phase complete, 514 NCP Phase starts 516 3.3.2: NAS Initiated EAP Authentication 518 In the case where the NAS sends the authenticating peer an EAP- 519 Request/Identity packet without first sending an EAP-Start packet to 520 the Diameter server, the conversation would appear as follows: 522 Authenticating Peer NAS Diameter Server 523 ------------------- --- --------------- 525 <- PPP LCP Request-EAP 526 auth 527 PPP LCP ACK-EAP 528 auth -> 529 <- PPP EAP-Request/ 530 Identity 531 PPP EAP-Response/ 532 Identity (MyID) -> 533 Diameter- 534 EAP-Request/ 535 EAP-Payload/ 536 EAP-Response/ 537 (MyID) -> 538 <- Diameter- 539 EAP-Answer/ 540 EAP-Payload/EAP-Request 541 OTP/OTP Challenge 542 <- PPP EAP-Request/ 543 OTP/OTP Challenge 544 PPP EAP-Response/ 545 OTP, OTPpw -> 546 Diameter- 547 EAP-Request/ 548 EAP-Payload/ 549 EAP-Response/ 550 OTP, OTPpw -> 551 <- Diameter- 552 EAP-Answer/ 553 EAP-Payload/EAP-Success 554 (other AVPs) 555 <- PPP EAP-Success 556 PPP Authentication 557 Phase complete, 558 NCP Phase starts 560 3.3.3: Server-Initiated Authentication 561 When a server has successfully authenticated and authorized a user, 562 it may include a timeout period to the authorization. The server can 563 later initiate an unsolicited re-authentication request to the user, 564 through the NAS. This method has the advantage of reducing the number 565 of round trips required for re-authentication/authorization. 567 Authenticating Peer NAS Diameter Server 568 ------------------- --- --------------- 570 <- Diameter-EAP-Ind/ 571 EAP-Payload/EAP-Request 572 OTP/OTP Challenge 573 <- PPP EAP-Request/ 574 OTP/OTP Challenge 575 PPP EAP-Response/ 576 OTP, OTPpw -> 577 Diameter- 578 EAP-Request/ 579 EAP-Payload/ 580 EAP-Response/ 581 OTP, OTPpw -> 582 <- Diameter- 583 EAP-Answer/ 584 EAP-Payload/EAP-Success 585 (other AVPs) 586 <- PPP EAP-Success 588 3.3.4: Example of failed EAP Authentication 590 In the case where the client fails EAP authentication, 591 the conversation would appear as follows: 593 Authenticating Peer NAS Diameter Server 594 ------------------- --- --------------- 596 <- PPP LCP Request-EAP 597 auth 598 PPP LCP ACK-EAP 599 auth -> 600 Diameter- 601 EAP-Request/ 602 EAP-Payload/Start -> 603 <- Diameter- 604 EAP-Answer/ 605 EAP-Payload/Identity 606 <- PPP EAP-Request/ 607 Identity 608 PPP EAP-Response/ 609 Identity (MyID) -> 610 Diameter- 611 EAP-Request/ 612 EAP-Payload/ 613 EAP-Response/ 614 (MyID) -> 615 <- Diameter- 616 EAP-Answer/ 617 EAP-Payload/EAP-Request 618 OTP/OTP Challenge 619 <- PPP EAP-Request/ 620 OTP/OTP Challenge 621 PPP EAP-Response/ 622 OTP, OTPpw -> 623 Diameter- 624 EAP-Request/ 625 EAP-Payload/ 626 EAP-Response/ 627 OTP, OTPpw -> 628 <- Diameter- 629 EAP-Answer/ 630 EAP-Payload/EAP-Failure 631 <- PPP EAP-Failure 633 <- LCP Terminate 635 3.3.5: Example of Diameter Server not supporting EAP 637 In the case that the Diameter server or proxy does not support EAP 638 extensions the conversation would appear as follows: 640 Authenticating Peer NAS Diameter Server 641 ------------------- --- --------------- 643 <- PPP LCP Request-EAP 644 auth 645 PPP LCP ACK-EAP 646 auth -> 647 Diameter 648 EAP-Request/ 649 EAP-Payload/Start -> 650 <- Diameter 651 Command-Unrecognized 652 <- PPP LCP Request-CHAP 653 auth 655 PPP LCP ACK-CHAP 656 auth -> 657 <- PPP CHAP Challenge 658 PPP CHAP Response -> 659 Diameter 660 AA-Request-> 661 <- Diameter 662 AA-Answer 663 <- PPP LCP 664 CHAP-Success 665 PPP Authentication 666 Phase complete, 667 NCP Phase starts 669 3.3.6: Example of Diameter Proxy not supporting EAP 671 In the case where the local Diameter Server does support the EAP 672 extensions but the remote Diameter Server does not, the conversation 673 would appear as follows: 675 Authenticating Peer NAS Diameter Server 676 ------------------- --- --------------- 678 <- PPP LCP Request-EAP 679 auth 680 PPP LCP ACK-EAP 681 auth -> 682 Diameter- 683 EAP-Request/ 684 EAP-Payload/Start -> 685 <- Diameter- 686 EAP-Answer/ 687 EAP-Payload/Identity 688 <- PPP EAP-Request/ 689 Identity 690 PPP EAP-Response/ 691 Identity 692 (MyID) -> 693 Diameter- 694 EAP-Request/ 695 EAP-Payload/EAP-Response/ 696 (MyID) -> 697 <- Diameter- 698 EAP-Answer 699 (proxied from remote 700 Diameter Server) 701 <- PPP LCP Request-CHAP 702 auth 703 PPP LCP ACK-CHAP 704 auth -> 705 <- PPP CHAP Challenge 706 PPP CHAP Response -> 707 Diameter 708 AA-Request-> 709 <- Diameter 710 AA-Answer 711 (proxied from remote 712 Diameter Server) 713 <- PPP LCP 714 CHAP-Success 715 PPP Authentication 716 Phase complete, 717 NCP Phase starts 719 3.3.7: Example of PPP Client not supporting EAP 721 In the case where the authenticating peer does not support EAP, but 722 where EAP is required for that user, the conversation would appear as 723 follows: 725 Authenticating Peer NAS Diameter Server 726 ------------------- --- --------------- 728 <- PPP LCP Request-EAP 729 auth 730 PPP LCP NAK-EAP 731 auth -> 732 <- PPP LCP Request-EAP 733 auth 734 PPP LCP NAK-EAP 735 auth -> 736 <- PPP LCP Request-CHAP 737 auth 738 PPP LCP ACK-CHAP 739 auth -> 740 <- PPP CHAP Challenge 741 PPP CHAP Response -> 743 Diameter- 744 AA-Request/ 745 User-Name, 746 CHAP-Password -> 747 <- Diameter- 748 EAP-Answer/ 749 EAP-Payload 750 <- LCP Terminate Req 752 4.0 References 754 [1] Rigney, et alia, "RADIUS", RFC-2138, April 1997 756 [2] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, "Diameter Base 757 Protocol", draft-calhoun-diameter-15.txt, IETF work in progress, 758 June 2000. 760 [3] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "Diameter NASREQ 761 Extension", draft-calhoun-diameter-nasreq-03.txt, IETF work in 762 progress, April 2000. 764 [4] L. J. Blunk, J. R. Vollbrecht, "PPP Extensible Authentication 765 Protocol (EAP)." RFC 2284, March 1998. 767 [5] N Haller, C. Metz, P. Nesset, M. Straw, "A One-Time Password 768 (OTP) System", RFC 2289, February 1998. 770 [6] Aboba, Beadles "The Network Access Identifier." RFC 2486. Janu- 771 ary 1999. 773 [7] R. Stewart et al., "Simple Control Transmission Protocol", 774 draft-ietf-sigtran-sctp-09.txt, IETF Work in Progress, April 775 2000. 777 5.0 Acknowledgements 779 The authors would like to thank Nenad Trifunovic, Tony Johansson and 780 Pankaj Patel for their participation in the Document Reading Party. 781 Also a big thanks to Erik Guttman and David Spence for their invalu- 782 able help in cleaning up this document. 784 The authors would also like to acknowledge the following people for 785 their contribution in the development of the Diameter protocol: 787 Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant, 788 Ignacio Goyret, Nancy Greene, Peter Heitman, Paul Krumviede, Fergal 789 Ladley, Ryan Moats, Victor Muslin, Kenneth Peirce, Sumit Vakil, John 790 R. Vollbrecht and Jeff Weisberg and Glen Zorn. 792 6.0 Authors' Addresses 794 Questions about this memo can be directed to: 796 Pat R. Calhoun 797 Network and Security Research Center, Sun Laboratories 798 Sun Microsystems, Inc. 799 15 Network Circle 800 Menlo Park, California, 94025 801 USA 803 Phone: 1-650-786-7733 804 Fax: 1-650-786-6445 805 E-mail: pcalhoun@eng.sun.com 807 Allan C. Rubens 808 Tut Systems, Inc. 809 220 E. Huron, Suite 260 810 Ann Arbor, MI 48104 811 USA 812 Phone: 1-734-995-1697 813 E-Mail: arubens@tutsys.com 815 Haseeb Akhtar 816 Wireless Technology Labs 817 Nortel Networks 818 2221 Lakeside Blvd. 819 Richardson, TX 75082-4399 820 USA 822 Phone: 1-972-684-8850 823 E-Mail: haseeb@nortelnetworks.com 825 William Bulley 826 Merit Network, Inc. 827 Building One, Suite 2000 828 4251 Plymouth Road 829 Ann Arbor, Michigan 48105-2785 830 USA 832 Phone: 1-734-764-9993 833 Fax: 1-734-647-3185 834 E-mail: web@merit.edu 836 Jeff Haag 837 Cisco Systems 838 7025 Kit Creek Road 839 PO Box 14987 840 Research Triangle Park, NC 27709 842 Phone: 1-919-392-2353 843 E-Mail: haag@cisco.com 845 7.0 Full Copyright Statement 847 Copyright (C) The Internet Society (2001). All Rights Reserved. 849 This document and translations of it may be copied and furnished to 850 others, and derivative works that comment on or otherwise explain it 851 or assist in its implementation may be prepared, copied, published 852 and distributed, in whole or in part, without restriction of any 853 kind, provided that the above copyright notice and this paragraph are 854 included on all such copies and derivative works. However, this docu- 855 ment itself may not be modified in any way, such as by removing the 856 copyright notice or references to the Internet Society or other 857 Internet organizations, except as needed for the purpose of develop- 858 ing Internet standards in which case the procedures for copyrights 859 defined in the Internet Standards process must be followed, or as 860 required to translate it into languages other than English. The lim- 861 ited permissions granted above are perpetual and will not be revoked 862 by the Internet Society or its successors or assigns. This document 863 and the information contained herein is provided on an "AS IS" basis 864 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 865 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 866 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 867 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 868 FITNESS FOR A PARTICULAR PURPOSE. 870 8.0 Expiration Date 872 This memo is filed as and 873 expires in July 2001.