idnits 2.17.1 draft-ietf-radius-eap-01.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-19) 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 240 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...' (19 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 567, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 571, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 577, 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 28 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, One Time Passwords, and others. In order to provide for 46 support of EAP within RADIUS, two new attributes, EAP-Message and Sig- 47 nature, were introduced as RADIUS extensions in [5]. This document 48 describes how these new attributes may be used for providing EAP sup- 49 port within 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 MUST 115 be 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, the RADIUS Server SHOULD return the user's identity 151 by inserting it in the User-Name attribute of subsequent Access-Chal- 152 lenge and Access-Accept packets. Without the user's identity, account- 153 ing 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 a One Time Password 218 (OTP) authentication. OTP is used only for illustrative purposes; 219 other authentication protocols could also have been used, although 220 they would show somewhat different behavior. For brevity, the history 221 of previous EAP messages (which will be transmitted in each Access- 222 Request and Access-Challenge packet) has been left out. 224 Authenticating Peer NAS RADIUS Server 225 ------------------- --- ------------- 227 <- PPP LCP Request-EAP 228 auth 229 PPP LCP ACK-EAP 230 auth -> 231 RADIUS 232 Access-Request/ 233 EAP-Message/Start -> 234 <- RADIUS 235 Access-Challenge/ 236 EAP-Message/Identity 237 <- PPP EAP-Request/ 238 Identity 239 PPP EAP-Response/ 240 Identity (MyID) -> 241 RADIUS 242 Access-Request/ 243 EAP-Message/ 244 EAP-Response/ 245 (MyID) -> 246 <- RADIUS 247 Access-Challenge/ 248 EAP-Message/EAP-Request 249 OTP/OTP Challenge 250 <- PPP EAP-Request/ 251 OTP/OTP Challenge 252 PPP EAP-Response/ 253 OTP, OTPpw -> 254 RADIUS 255 Access-Request/ 256 EAP-Message/ 257 EAP-Response/ 258 OTP, OTPpw -> 259 <- RADIUS 260 Access-Accept/ 261 EAP-Message/EAP-Success 262 (other attributes) 263 <- PPP EAP-Success 264 PPP Authentication 265 Phase complete, 266 NCP Phase starts 268 In the case where the NAS sends the authenticating peer an EAP- 269 Request/Identity packet without first sending an EAP-Start packet to 270 the RADIUS server, the conversation would appear as follows: 272 Authenticating Peer NAS RADIUS Server 273 ------------------- --- ------------- 275 <- PPP LCP Request-EAP 276 auth 277 PPP LCP ACK-EAP 278 auth -> 279 <- PPP EAP-Request/ 280 Identity 281 PPP EAP-Response/ 282 Identity (MyID) -> 283 RADIUS 284 Access-Request/ 285 EAP-Message/ 286 EAP-Response/ 287 (MyID) -> 288 <- RADIUS 289 Access-Challenge/ 290 EAP-Message/EAP-Request 291 OTP/OTP Challenge 292 <- PPP EAP-Request/ 293 OTP/OTP Challenge 294 PPP EAP-Response/ 295 OTP, OTPpw -> 296 RADIUS 297 Access-Request/ 298 EAP-Message/ 299 EAP-Response/ 300 OTP, OTPpw -> 301 <- RADIUS 302 Access-Accept/ 303 EAP-Message/EAP-Success 304 (other attributes) 305 <- PPP EAP-Success 306 PPP Authentication 307 Phase complete, 308 NCP Phase starts 310 In the case where the client fails EAP authentication, the conversa- 311 tion would appear as follows: 313 Authenticating Peer NAS RADIUS Server 314 ------------------- --- ------------- 315 <- PPP LCP Request-EAP 316 auth 317 PPP LCP ACK-EAP 318 auth -> 319 Access-Request/ 320 EAP-Message/Start -> 321 <- RADIUS 322 Access-Challenge/ 323 EAP-Message/Identity 324 <- PPP EAP-Request/ 325 Identity 326 PPP EAP-Response/ 327 Identity (MyID) -> 328 RADIUS 329 Access-Request/ 330 EAP-Message/ 331 EAP-Response/ 332 (MyID) -> 333 <- RADIUS 334 Access-Challenge/ 335 EAP-Message/EAP-Request 336 OTP/OTP Challenge 337 <- PPP EAP-Request/ 338 OTP/OTP Challenge 339 PPP EAP-Response/ 340 OTP, OTPpw -> 341 RADIUS 342 Access-Request/ 343 EAP-Message/ 344 EAP-Response/ 345 OTP, OTPpw -> 346 <- RADIUS 347 Access-Reject/ 348 EAP-Message/EAP-Failure 349 <- PPP EAP-Failure 350 (client disconnected) 352 In the case that the RADIUS server or proxy does not support EAP-Mes- 353 sage, the conversation would appear as follows: 355 Authenticating Peer NAS RADIUS Server 356 ------------------- --- ------------- 358 <- PPP LCP Request-EAP 359 auth 360 PPP LCP ACK-EAP 361 auth -> 362 RADIUS 363 Access-Request/ 364 EAP-Message/Start -> 365 <- RADIUS 366 Access-Reject 367 <- PPP LCP Request-CHAP 368 auth 370 PPP LCP ACK-CHAP 371 auth -> 372 <- PPP CHAP Challenge 373 PPP CHAP Response -> 374 RADIUS 375 Access-Request-> 376 <- RADIUS 377 Access-Accept 378 <- PPP LCP 379 CHAP-Success 380 PPP Authentication 381 Phase complete, 382 NCP Phase starts 384 In the case where the local RADIUS Server does support EAP-Message, 385 but the remote RADIUS Server does not, the conversation would appear 386 as follows: 388 Authenticating Peer NAS RADIUS Server 389 ------------------- --- ------------- 391 <- PPP LCP Request-EAP 392 auth 393 PPP LCP ACK-EAP 394 auth -> 395 RADIUS 396 Access-Request/ 397 EAP-Message/Start -> 398 <- RADIUS 399 Access-Challenge/ 400 EAP-Message/Identity 401 <- PPP EAP-Request/ 402 Identity 403 PPP EAP-Response/ 404 Identity 405 (MyID) -> 406 RADIUS 407 Access-Request/ 408 EAP-Message/EAP-Response/ 409 (MyID) -> 410 <- RADIUS 411 Access-Reject 412 (proxied from remote 413 RADIUS Server) 414 <- PPP LCP Request-CHAP 415 auth 416 PPP LCP ACK-CHAP 417 auth -> 418 <- PPP CHAP Challenge 419 PPP CHAP Response -> 420 RADIUS 421 Access-Request-> 422 <- RADIUS 423 Access-Accept 424 (proxied from remote 425 RADIUS Server) 426 <- PPP LCP 427 CHAP-Success 428 PPP Authentication 429 Phase complete, 430 NCP Phase starts 432 In the case where the authenticating peer does not support EAP, but 433 where EAP is required for that user, the conversation would appear as 434 follows: 436 Authenticating Peer NAS RADIUS Server 437 ------------------- --- ------------- 439 <- PPP LCP Request-EAP 440 auth 441 PPP LCP NAK-EAP 442 auth -> 443 <- PPP LCP Request-CHAP 444 auth 445 PPP LCP ACK-CHAP 446 auth -> 447 <- PPP CHAP Challenge 448 PPP CHAP Response -> 449 RADIUS 450 Access-Request/ 451 User-Name, 452 CHAP-Password -> 453 <- RADIUS 454 Access-Challenge/ 455 EAP-Message 456 (User Disconnected) 458 5. Alternative uses 460 Currently the conversation between the backend security server and the 461 RADIUS server is proprietary because of lack of standardization. In 462 order to increase standardization and provide interoperability between 463 Radius vendors and backend security vendors, it is recommended that 464 RADIUS-encapsulated EAP be used for this conversation. 466 This has the advantage of allowing the RADIUS server to support EAP 467 without the need for authentication-specific code within the RADIUS 468 server. Authentication-specific code can then reside on a backend 469 security server instead. 471 In the case where RADIUS-encapsulated EAP is used in a conversation 472 between a RADIUS server and a backend security server, the Security 473 Server will typically return an Access-Accept/EAP-Success message 474 without inclusion of the expected attributes currently returned in an 475 Access-Accept. This means that the RADIUS server MUST add these 476 attributes prior to sending an Access-Accept/EAP-Success message to 477 the NAS. 479 6. Attributes 481 6.1. EAP-Message 483 Description 485 This attribute encapsulates Extensible Authentication Protocol [1] 486 packets so as to allow the NAS to authenticate dial-in users via 487 EAP without having to understand the protocol. 489 The NAS places EAP messages received from the authenticating peer 490 into one or more EAP-Message attributes and forwards them to the 491 RADIUS Server within an Access-Request message. The RADIUS Server 492 may then return EAP message in Access-Challenge, Access-Accept and 493 Access-Reject packets. 495 Access-Request packets including one or more EAP-Message attributes 496 MUST also contain a Signature attribute, described in [5], in order 497 to provide for authentication of the shuttled EAP packets. Access- 498 Requests including an EAP-Message attribute without a Signature 499 attribute SHOULD be silently discarded by the RADIUS server. A 500 RADIUS Server supporting EAP-Message MUST calculate the correct 501 value of the Signature and silently discard the packet if it does 502 not match the value sent. A RADIUS Server not supporting EAP-Mes- 503 sage MUST return an Access-Reject. A RADIUS Server receiving EAP 504 messages that it does not understand SHOULD return an Access- 505 Reject. 507 A summary of the EAP-Message attribute format is shown below. The 508 fields are transmitted from left to right. 510 0 1 2 3 511 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 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Type | Length | Sequence No. | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | String... 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 Type 520 67 for EAP-Message 522 Length 524 >=5 (EAP packet enclosed) 525 =2 (EAP start message) 527 Sequence Number 528 The Sequence Number field, which is two octets in length, is used 529 in order to build a "history" of the transaction. The EAP-Message 530 attribute with the highest identifier represents the current packet 531 to process. The history is passed along in each Access- 532 request/Access-Challenge in order to support the concept of RADIUS 533 backup servers, as described earlier. 535 EAP-Message attributes with the same sequence number are to be con- 536 catenated, in order to allow an EAP packet to be larger than the 537 253 octet limit for a RADIUS attribute. 539 String 541 The String field includes EAP packets, as defined in [1]: 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | Code | Identifier | Length | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | | 547 / / 548 / Data / 549 | | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 7. Acknowledgments 554 Thanks to Dave Dawson and Karl Fox of Ascend, and Glen Zorn and Naren- 555 dra Gidwani of Microsoft for useful discussions of this problem space. 557 8. References 559 [1] L. J. Blunk, J. R. Vollbrecht. "PPP Extensible Authentication 560 Protocol (EAP)." draft-ietf-pppext-eap-auth-02.txt, Merit Network, 561 Inc., June, 1996. 563 [2] A. Rubens, P.R. Calhoun. "DIAMETER Extensible Authentication Pro- 564 tocol Support." draft-calhoun-diameter-eap-00.txt, Merit Network, 565 Inc., US Robotics Access Corp., February, 1997. 567 [3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- 568 cation Dial In User Service (RADIUS)." RFC 2058, Livingston, Merit, 569 Daydreamer, January, 1997. 571 [4] C. Rigney. "RADIUS Accounting." RFC 2059, Livingston, January, 572 1997. 574 [5] C. Rigney, W. Willats. "RADIUS Extensions." draft-ietf-radius- 575 ext-00.txt, Livingston, January, 1997. 577 [6] R. Rivest, S. Dusse. "The MD5 Message-Digest Algorithm", RFC 578 1321, MIT Laboratory for Computer Science, RSA Data Security Inc., 579 April 1992. 581 [7] S. Bradner. "Key words for use in RFCs to Indicate Requirement 582 Levels." draft-bradner-key-words-02.txt, Harvard University, August, 583 1996. 585 9. Authors' Addresses 587 Pat R. Calhoun 588 US Robotics Access Corp. 589 8100 N. McCormick Blvd. 590 Skokie, IL 60076-2999 592 Phone: 847-342-6898 593 EMail: pcalhoun@usr.com 595 Allan C. Rubens 596 Merit Network, Inc. 597 4251 Plymouth Rd. 598 Ann Arbor, MI 48105-2785 600 Phone: 313-647-0417 601 EMail: acr@merit.edu 603 Bernard Aboba 604 Microsoft Corporation 605 One Microsoft Way 606 Redmond, WA 98052 608 Phone: 206-936-6605 609 EMail: bernarda@microsoft.com