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