idnits 2.17.1 draft-ietf-radius-eap-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 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 141 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 241 instances of too long lines in the document, the longest one being 7 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 66: '... MUST This word, or the adjec...' RFC 2119 keyword, line 70: '... MUST NOT This phrase, or the phr...' RFC 2119 keyword, line 73: '... SHOULD This word, or the adje...' RFC 2119 keyword, line 79: '... SHOULD NOT...' RFC 2119 keyword, line 86: '... MAY This word, or the adj...' (16 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 14 has weird spacing: '...), its areas...' == Line 15 has weird spacing: '... its worki...' == Line 19 has weird spacing: '... and may ...' == Line 20 has weird spacing: '...afts as refer...' == Line 23 has weird spacing: '... To learn...' == (136 more instances...) -- 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 535, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 539, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 545, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-calhoun-diameter-eap-00 -- Possible downref: Normative reference to a draft: ref. '2' ** Obsolete normative reference: RFC 2058 (ref. '3') (Obsoleted by RFC 2138) ** Obsolete normative reference: RFC 2059 (ref. '4') (Obsoleted by RFC 2139) == Outdated reference: A later version (-06) exists of draft-ietf-radius-ext-00 ** Downref: Normative reference to an Informational draft: draft-ietf-radius-ext (ref. '5') ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '6') Summary: 17 errors (**), 0 flaws (~~), 14 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RADIUS Working Group Pat Calhoun 3 INTERNET-DRAFT US Robotics Access Corp. 4 Allan C. Rubens 5 19 February 1997 Merit Network, Inc. 6 Bernard Aboba 7 Microsoft 9 Extensible Authentication Protocol Support in RADIUS 11 1. Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working docu- 14 ments of the Internet Engineering Task Force (IETF), its areas, and 15 its working groups. Note that other groups may also distribute work- 16 ing documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference mate- 21 rial or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 25 Directories on ds.internic.net (US East Coast), nic.nordu.net 26 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 28 The distribution of this memo is unlimited. It is filed as , and expires September 1, 1997. Please send 30 comments to the authors. 32 2. Abstract 34 The Extensible Authentication Protocol (EAP) is a PPP extension that 35 provides support for additional authentication methods within PPP. 36 This document describes how the EAP-Message and Signature attributes 37 may be used for providing EAP support within RADIUS. 39 3. Introduction 41 The Extensible Authentication Protocol (EAP), described in [1], pro- 42 vides a standard mechanism for support of additional authentication 43 methods within PPP. Through the use of EAP, support for a number of 44 authentication schemes may be added, including token cards, Kerberos, 45 Public Key, S/Key, and others. In order to provide for support of EAP 46 within RADIUS, two new attributes, EAP-Message and Signature, were 47 introduced as RADIUS extensions in [5]. This document describes how 48 these new attributes may be used for providing EAP support within 49 RADIUS. 51 The scheme described here is similar to that proposed in [2], in that 52 the RADIUS server is used to shuttle RADIUS-encapsulated EAP Packets 53 between the NAS and a backend security server. While the conversation 54 between the RADIUS server and the backend security server will typi- 55 cally occur using a proprietary protocol developed by the backend 56 security server vendor, it is also possible to use RADIUS-encapsulated 57 EAP via the EAP-Message attribute. This has the advantage of allowing 58 the RADIUS server to support EAP without the need for authentication- 59 specific code, which can instead reside on a backend security server. 61 3.1. Requirements language 63 This specification uses the same words as [7] for defining the signif- 64 icance of each particular requirement. These words are: 66 MUST This word, or the adjectives "REQUIRED" or "SHALL", means 67 that the definition is an absolute requirement of the speci- 68 fication. 70 MUST NOT This phrase, or the phrase "SHALL NOT", means that the defi- 71 nition is an absolute prohibition of the specification. 73 SHOULD This word, or the adjective "RECOMMENDED", means that there 74 may exist valid reasons in particular circumstances to 75 ignore a particular item, but the full implications must be 76 understood and carefully weighed before choosing a different 77 course. 79 SHOULD NOT 80 This phrase means that there may exist valid reasons in par- 81 ticular circumstances when the particular behavior is 82 acceptable or even useful, but the full implications should 83 be understood and the case carefully weighed before imple- 84 menting any behavior described with this label. 86 MAY This word, or the adjective "OPTIONAL", means that an item 87 is truly optional. One vendor may choose to include the 88 item because a particular marketplace requires it or because 89 the vendor feels that it enhances the product while another 90 vendor may omit the same item. An implementation which does 91 not include a particular option MUST be prepared to interop- 92 erate with another implementation which does include the 93 option, though perhaps with reduced functionality. In the 94 same vein an implementation which does include a particular 95 option MUST be prepared to interoperate with another imple- 96 mentation which does not include the option.(except, of 97 course, for the feature the option provides) 99 An implementation is not compliant if it fails to satisfy one or more 100 of the must or must not requirements for the protocols it implements. 101 An implementation that satisfies all the must, must not, should and 102 should not requirements for its protocols is said to be 103 "unconditionally compliant"; one that satisfies all the must and must 104 not requirements but not all the should or should not requirements for 105 its protocols is said to be "conditionally compliant." 107 4. Protocol overview 109 The EAP conversation between the authenticating peer and the NAS 110 begins with the negotiation of EAP within LCP. Once EAP has been nego- 111 tiated, the NAS will typically send to the RADIUS server a RADIUS 112 Access-Request packet containing an EAP-Message attribute signifying 113 EAP-Start. EAP-Start is indicated by sending an EAP-Message attribute 114 with a length of 2 (no data). The Port number and NAS Identifier are 115 included in the attributes issued by the NAS in the Access-Request 116 packet. 118 If the RADIUS server supports EAP, it MUST respond with an Access- 119 Challenge packet containing an EAP-Message attribute. The EAP-Message 120 attribute includes an encapsulated EAP packet which is then passed on 121 to the authenticating peer. The Access-Challenge typically will con- 122 tain an EAP-Message attribute encapsulating an EAP-Request/Identity 123 message, requesting the authenticating peer to identify itself. The 124 NAS will then respond with a RADIUS Access-Request packet containing 125 an EAP-Message attribute encapsulating an EAP-Response, etc. The con- 126 versation continues until either a RADIUS Access-Reject packet is 127 received (with an EAP-Message attribute encapsulating EAP-Failure) 128 which results in the NAS disconnecting the user, or a RADIUS Access- 129 Accept packet is received (with an EAP-Message attribute encapsulating 130 EAP-Success) successfully ending the authentication phase. Note that 131 if a RADIUS Access-Reject packet with an EAP-Message attribute encap- 132 sulating EAP-Failure is received from the RADIUS Server, the NAS 133 SHOULD issue an LCP Terminate Request to the authenticating peer. 135 The above scenario creates a situation in which the NAS never needs to 136 manipulate an EAP packet. An alternative may be used in situations 137 where an EAP-Request/Identity message will always be sent by the NAS 138 to the authenticating peer. This involves having the NAS send an EAP- 139 Request/Identity message to the authenticating peer, and forwarding 140 the EAP-Response/Identity packet to the RADIUS server in the EAP-Mes- 141 sage attribute of a RADIUS Access-Request packet. While this approach 142 will save a round-trip, it cannot be universally employed. There are 143 circumstances in which the user's identity may not be needed (such as 144 when authentication and accounting is handled based on the calling or 145 called phone number), and therefore an EAP-Request/Identity packet may 146 not necessarily be issued by the NAS to the authenticating peer. 148 Unless the NAS interprets the EAP-Response/Identity packet returned by 149 the authenticating peer, it will not have access to the user's iden- 150 tity. Therefore, it is suggested that the RADIUS Server return the 151 user's identity by inserting it in the User-Name attribute of subse- 152 quent Access-Challenge and Access-Accept packets. Without the user's 153 identity, accounting and billing becomes very difficult to manage. 155 In cases where a backup RADIUS servers is available, were the primary 156 server to fail at any time during the EAP conversation, it would be 157 desirable for the NAS to be able to redirect the conversation to an 158 alternate RADIUS server. However, for the backup server to be able to 159 pick up the conversation, it must be provided with the state of the 160 EAP conversation prior to the interruption. 162 This can be accomplished by having the RADIUS Access-Request include 163 the series of EAP-Message attributes representing the previous history 164 of the EAP conversation. Similarly, the RADIUS Challenge returned by 165 the RADIUS server must also include all previous EAP-Message 166 attributes. The sequence number field in the EAP-Message attribute 167 MUST be used in order to determine which attribute is to be processed. 168 The attribute with the highest sequence number is the most recent 169 attribute. 171 The RADIUS Access-Accept/EAP-Message/EAP-Success packet MUST contain 172 all of the expected attributes which are currently returned in an 173 Access-Accept packet. 175 For proxied RADIUS requests there are two methods of processing. If 176 the domain is determined based on the DNIS the RADIUS Server may proxy 177 the initial RADIUS Access-Request/EAP-Start. If the domain is deter- 178 mined based on the user's identity, the local RADIUS Server MUST 179 respond with a RADIUS Access-Challenge/EAP-Identity packet. The 180 response from the authenticating peer MUST be proxied to the final 181 authentication server. 183 For proxied RADIUS requests, the NAS may receive an Access-Reject 184 packet in response to its Access-Request/EAP-Identity packet. This 185 would occur if the message was proxied to a RADIUS Server which does 186 not support the EAP-Message extension. At this point, the NAS MUST 187 re-open LCP with the authenticating peer and request either CHAP or 188 PAP as the authentication protocol. Again, such an Access-Reject 189 packet indicating lack of EAP capability will not contain an EAP-Mes- 190 sage attribute. 192 If the NAS is unable to negotiate EAP with the authenticating peer, 193 what happens next is a matter of policy. In circumstances where EAP is 194 required of all users accessing the NAS, the NAS MUST disconnect the 195 user. However, in circumstances where EAP is mandatory for some users, 196 and optional or not required for others, the decision cannot be made 197 until the user's identity is ascertained. In this case, the NAS will 198 negotiate another authentication method, such as CHAP, and will pass 199 the User-Name and CHAP-Password attributes to the RADIUS Server in an 200 Access-Request packet. If the user is not required to use EAP, then 201 the RADIUS Server will respond with an Access-Accept or Access-Reject 202 packet as appropriate. However, should the user require EAP, then the 203 RADIUS Server will respond with an Access-Challenge packet containing 204 an EAP-Message attribute. The EAP-Message attribute will either encap- 205 sulate an EAP-Request/Identity packet, or if the RADIUS Server makes 206 use of the User-Name attribute in the Access-Request, it may encapsu- 207 late an EAP challenge. On receiving the EAP-Message attribute, the NAS 208 will either attempt to negotiate EAP if it had not done so previously, 209 or if negotiation had previously been attempted and failed, it MUST 210 disconnect the user. 212 The NAS is not responsible for the retransmission of any EAP messages. 213 The authenticating peer and the RADIUS Server are responsible for any 214 retransmissions. 216 The example below shows the conversation between the authenticating 217 peer, NAS, and RADIUS server, for the case of an S/Key authentication. 218 S/Key is used only for illustrative purposes; other authentication 219 protocols could also have been used, although they would show somewhat 220 different behavior. 222 Authenticating Peer NAS RADIUS Server 223 ------------------- --- ------------- 225 <- PPP LCP EAP-Request 226 PPP LCP EAP ACK -> 227 RADIUS 228 Access-Request/ 229 EAP-Message/Start -> 230 <- RADIUS 231 Access-Challenge/ 232 EAP-Message/Identity 233 <- PPP EAP-Request/ 234 Identity 235 PPP EAP-Response/ 236 Identity (MyID) -> 237 RADIUS 238 Access-Request/ 239 EAP-Message/ 240 EAP-Response/ 241 (MyID) -> 242 <- RADIUS 243 Access-Challenge/ 244 EAP-Message/EAP-Request 245 S-Key/S-Key Challenge 246 <- PPP EAP-Request/ 247 S-Key/ 248 S-Key Challenge 249 PPP EAP-Response/ 250 S-Key, S-Keypw -> 251 RADIUS 252 Access-Request/ 253 EAP-Message/ 254 EAP-Response/ 255 S-Key, S-Keypw -> 256 <- RADIUS 257 Access-Accept/ 258 EAP-Message/EAP-Success 259 (other attributes) 260 <- PPP EAP-Success 261 IPCP phase starts 262 In the case where the NAS sends the authenticating peer an EAP- 263 Request/Identity packet without first sending an EAP-Start packet to 264 the RADIUS server, the conversation would appear as follows: 266 Authenticating Peer NAS RADIUS Server 267 ------------------- --- ------------- 269 <- PPP LCP EAP-Request 270 PPP LCP EAP ACK -> 271 <- PPP EAP-Request/ 272 Identity 273 PPP EAP-Response/ 274 Identity (MyID) -> 275 RADIUS 276 Access-Request/ 277 EAP-Message/ 278 EAP-Response/ 279 (MyID) -> 280 <- RADIUS 281 Access-Challenge/ 282 EAP-Message/EAP-Request 283 S-Key/S-Key Challenge 284 <- PPP EAP-Request/ 285 S-Key/ 286 S-Key Challenge 287 PPP EAP-Response/ 288 S-Key, S-Keypw -> 289 RADIUS 290 Access-Request/ 291 EAP-Message/ 292 EAP-Response/ 293 S-Key, S-Keypw -> 294 <- RADIUS 295 Access-Accept/ 296 EAP-Message/EAP-Success 297 (other attributes) 298 <- PPP EAP-Success 299 IPCP phase starts 301 In the case where the client fails EAP authentication, the conversa- 302 tion would appear as follows: 304 Authenticating Peer NAS RADIUS Server 305 ------------------- --- ------------- 307 <- PPP LCP EAP-Request 308 PPP LCP EAP ACK -> 309 RADIUS 310 Access-Request/ 311 EAP-Message/Start -> 312 <- RADIUS 313 Access-Challenge/ 314 EAP-Message/Identity 315 <- PPP EAP-Request/ 316 Identity 317 PPP EAP-Response/ 318 Identity (MyID) -> 319 RADIUS 320 Access-Request/ 321 EAP-Message/ 322 EAP-Response/ 323 (MyID) -> 324 <- RADIUS 325 Access-Challenge/ 326 EAP-Message/EAP-Request 327 S-Key/S-Key Challenge 328 <- PPP EAP-Request/ 329 S-Key/ 330 S-Key Challenge 331 PPP EAP-Response/ 332 S-Key, S-Keypw -> 333 RADIUS 334 Access-Request/ 335 EAP-Message/ 336 EAP-Response/ 337 S-Key, S-Keypw -> 338 <- RADIUS 339 Access-Reject/ 340 EAP-Message/EAP-Failure 341 <- PPP EAP-Failure 342 (client disconnected) 344 In the case that the RADIUS server or proxy does not support EAP-Mes- 345 sage, the conversation would appear as follows: 347 Authenticating Peer NAS RADIUS Server 348 ------------------- --- ------------- 350 <- PPP LCP EAP-Request 351 PPP LCP EAP ACK -> 352 RADIUS 353 Access-Request/ 354 EAP-Message/Start -> 355 <- RADIUS 356 Access-Reject 357 <- PPP LCP 358 CHAP-Request 359 PPP LCP 360 CHAP-Response-> 361 RADIUS 362 Access-Request-> 363 <- RADIUS 364 Access-Accept 366 In the case where the local RADIUS Server does support EAP-Message, 367 but the remote RADIUS Server does not, the conversation would appear 368 as follows: 370 Authenticating Peer NAS RADIUS Server 371 ------------------- --- ------------- 373 <- PPP LCP EAP-Request 374 PPP LCP EAP ACK -> 375 RADIUS 376 Access-Request/ 377 EAP-Message/Start -> 378 <- RADIUS 379 Access-Challenge/ 380 EAP-Message/Identity 381 <- PPP EAP-Request/ 382 Identity 383 PPP EAP-Response/ 384 Identity 385 (MyID) -> 386 RADIUS 387 Access-Request/ 388 EAP-Message/EAP-Response/ 389 (MyID) -> 390 <- RADIUS 391 Access-Reject 392 (proxied from remote 393 RADIUS Server) 394 <- PPP LCP 395 CHAP-Request 396 PPP LCP 397 CHAP-Response-> 398 RADIUS 399 Access-Request-> 400 <- RADIUS 401 Access-Accept 402 (proxied from remote 403 RADIUS Server) 405 In the case where the authenticating peer does not support EAP, but 406 where EAP is required for that user, the conversation would appear as 407 follows: 409 Authenticating Peer NAS RADIUS Server 410 ------------------- --- ------------- 412 <- PPP LCP EAP-Request 413 PPP LCP EAP NACK -> 414 <- PPP LCP CHAP-Request 415 PPP LCP 416 CHAP-Response -> 417 RADIUS 418 Access-Request/ 419 User-Name, 420 CHAP-Password -> 421 <- RADIUS 422 Access-Challenge/ 423 EAP-Message 425 (User Disconnected) 427 5. Alternative uses 429 While the conversation between the RADIUS server and the backend 430 security server will typically occur using a proprietary protocol 431 developed by the backend security server vendor, it is also possible 432 to use RADIUS-encapsulated EAP via the EAP-Message and Signature 433 attributes. This has the advantage of allowing the RADIUS server to 434 support EAP without the need for authentication-specific code within 435 the RADIUS server. Authentication-specific code can then reside on a 436 backend security server instead. 438 In the case where RADIUS-encapsulated EAP is used in a conversation 439 between a RADIUS server and a backend security server, the Security 440 Server will typically return an Access-Accept/EAP-Success message 441 without inclusion of the expected attributes currently returned in an 442 Access-Accept. This means that the RADIUS server will need to add 443 these attributes prior to sending an Access-Accept/EAP-Success message 444 to the NAS. 446 6. Attributes 448 6.1. EAP-Message 450 Description 452 This attribute encapsulates Extensible Authentication Protocol [1] 453 packets so as to allow the NAS to authenticate dial-in users via 454 EAP without having to understand the protocol. 456 The NAS places EAP messages received from the authenticating peer 457 into one or more EAP-Message attributes and forwards them to the 458 RADIUS Server within an Access-Request message. The RADIUS Server 459 may then return EAP message in Access-Challenge, Access-Accept and 460 Access-Reject packets. 462 Access-Request packets including one or more EAP-Message attributes 463 MUST also contain a Signature attribute, described in [5], in order 464 to provide for authentication of the shuttled EAP packets. Access- 465 Requests including an EAP-Message attribute without a Signature 466 attribute SHOULD be silently discarded by the RADIUS server. A 467 RADIUS Server supporting EAP-Message MUST calculate the correct 468 value of the Signature and silently discard the packet if it does 469 not match the value sent. A RADIUS Server not supporting EAP-Mes- 470 sage MUST return an Access-Reject. A RADIUS Server receiving EAP 471 messages that it does not understand SHOULD return an Access- 472 Reject. 474 A summary of the EAP-Message attribute format is shown below. The 475 fields are transmitted from left to right. 477 0 1 2 3 478 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Type | Length | Sequence No. | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | String... 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 Type 487 67 for EAP-Message 489 Length 491 >=5 (EAP packet enclosed) 492 =2 (EAP start message) 494 Sequence Number 496 The Sequence Number field, which is two octets in length, is used 497 in order to build a "history" of the transaction. The EAP-Message 498 attribute with the highest identifier represents the current packet 499 to process. The history is passed along in each Access- 500 request/Access-Challenge in order to support the concept of RADIUS 501 backup servers, as described earlier. 503 EAP-Message attributes with the same sequence number are to be con- 504 catenated, in order to allow an EAP packet to be larger than the 505 253 octet limit for a RADIUS attribute. 507 String 509 The String field includes EAP packets, as defined in [1]: 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Code | Identifier | Length | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | | 515 / / 516 / Data / 517 | | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 7. Acknowledgments 522 Thanks to Dave Dawson and Karl Fox of Ascend, and Glen Zorn and Naren- 523 dra Gidwani of Microsoft for useful discussions of this problem space. 525 8. References 527 [1] L. J. Blunk, J. R. Vollbrecht. "PPP Extensible Authentication 528 Protocol (EAP)." draft-ietf-pppext-eap-auth-02.txt, Merit Network, 529 Inc., June, 1996. 531 [2] A. Rubens, P.R. Calhoun. "DIAMETER Extensible Authentication Pro- 532 tocol Support." draft-calhoun-diameter-eap-00.txt, Merit Network, 533 Inc., US Robotics Access Corp., February, 1997. 535 [3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- 536 cation Dial In User Service (RADIUS)." RFC 2058, Livingston, Merit, 537 Daydreamer, January, 1997. 539 [4] C. Rigney. "RADIUS Accounting." RFC 2059, Livingston, January, 540 1997. 542 [5] C. Rigney, W. Willats. "RADIUS Extensions." draft-ietf-radius- 543 ext-00.txt, Livingston, January, 1997. 545 [6] R. Rivest, S. Dusse. "The MD5 Message-Digest Algorithm", RFC 546 1321, MIT Laboratory for Computer Science, RSA Data Security Inc., 547 April 1992. 549 [7] S. Bradner. "Key words for use in RFCs to Indicate Requirement 550 Levels." draft-bradner-key-words-02.txt, Harvard University, August, 551 1996. 553 9. Authors' Addresses 555 Pat R. Calhoun 556 US Robotics Access Corp. 557 8100 N. McCormick Blvd. 558 Skokie, IL 60076-2999 560 Phone: 847-342-6898 561 EMail: pcalhoun@usr.com 563 Allan C. Rubens 564 Merit Network, Inc. 565 4251 Plymouth Rd. 566 Ann Arbor, MI 48105-2785 568 Phone: 313-647-0417 569 EMail: acr@merit.edu 571 Bernard Aboba 572 Microsoft Corporation 573 One Microsoft Way 574 Redmond, WA 98052 576 Phone: 206-936-6605 577 EMail: bernarda@microsoft.com