idnits 2.17.1 draft-ietf-radius-ext-00.txt: 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** 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 104: '... MUST This word, or the adjecti...' RFC 2119 keyword, line 107: '... MUST NOT This phrase means that th...' RFC 2119 keyword, line 110: '... SHOULD This word, or the adjecti...' RFC 2119 keyword, line 116: '... MAY This word, or the adjecti...' RFC 2119 keyword, line 118: '...h does not include this option MUST be...' (22 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 256 has weird spacing: '...y a few piece...' == Line 434 has weird spacing: '... passed in an...' -- 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 (January 1997) is 9963 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'Note 1' on line 1005 ** Obsolete normative reference: RFC 2058 (ref. '1') (Obsoleted by RFC 2138) ** Obsolete normative reference: RFC 2059 (ref. '2') (Obsoleted by RFC 2139) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '3') Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RADIUS Working Group C Rigney 3 INTERNET-DRAFT Livingston 4 W Willats 5 Cyno Technologies 6 expires in six months January 1997 8 RADIUS Extensions 9 draft-ietf-radius-ext-00.txt 11 Status of this Memo 13 This document is a submission to the RADIUS Working Group of the 14 Internet Engineering Task Force (IETF). Comments should be submitted 15 to the ietf-radius@livingston.com mailing list. 17 Distribution of this memo is unlimited. 19 This document is an Internet-Draft. 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 To learn the current status of any Internet-Draft, please check the 30 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 31 Directories on on ftp.is.co.za (Africa), nic.nordu.net (Europe), 32 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 33 ftp.isi.edu (US West Coast). 35 Abstract 37 This document describes additional attributes for carrying 38 authentication, authorization and accounting information between a 39 Network Access Server (NAS) and a shared Accounting Server using the 40 Remote Authentication Dial In User Service (RADIUS) protocol 41 described in RFC 2058 and RFC 2059. 43 DRAFT RADIUS Extensions January 1997 45 Table of Contents 47 1. Introduction .......................................... 1 48 1.1 Specification of Requirements ................... 1 49 1.2 Terminology ..................................... 1 51 2. Operation ............................................. 2 52 2.1 RADIUS support for Apple Remote Access .......... 2 54 3. Packet Format ......................................... 8 56 4. Packet Types .......................................... 8 58 5. Attributes ............................................ 8 59 5.1 Prompt .......................................... 10 60 5.2 Connect-Info .................................... 10 61 5.3 Signature ....................................... 11 62 5.4 EAP-Message ..................................... 12 63 5.5 Configuration-Token ............................. 13 64 5.6 Password-Retry .................................. 14 65 5.7 ARAP-Password ................................... 15 66 5.8 ARAP-Features ................................... 16 67 5.9 ARAP-Zone-Access ................................ 17 68 5.10 ARAP-Security ................................... 18 69 5.11 ARAP-Security-Data .............................. 18 70 5.12 Table of Attributes ............................. 19 72 Security Considerations ...................................... 20 74 References ................................................... 20 76 Acknowledgements ............................................. 20 78 Chair's Address .............................................. 21 80 Author's Addresses ........................................... 21 82 DRAFT RADIUS Extensions January 1997 84 1. Introduction 86 RFC 2058 [1] describes the RADIUS Protocol as it is implemented and 87 deployed today, and RFC 2059 [2] describes how Accounting can be 88 performed with RADIUS. 90 This Internet-Draft suggests several additional Attributes that can 91 be added to RADIUS to perform various useful functions. These 92 Attributes do not have extensive field experience yet and should 93 therefore be considered experimental. 95 All attributes are comprised of variable length Type-Length-Value 96 3-tuples. New attribute values can be added without disturbing 97 existing implementations of the protocol. 99 1.1. Specification of Requirements 101 In this document, several words are used to signify the requirements 102 of the specification. These words are often capitalized. 104 MUST This word, or the adjective "required", means that the 105 definition is an absolute requirement of the specification. 107 MUST NOT This phrase means that the definition is an absolute 108 prohibition of the specification. 110 SHOULD This word, or the adjective "recommended", means that there 111 may exist valid reasons in particular circumstances to 112 ignore this item, but the full implications must be 113 understood and carefully weighed before choosing a 114 different course. 116 MAY This word, or the adjective "optional", means that this 117 item is one of an allowed set of alternatives. An 118 implementation which does not include this option MUST be 119 prepared to interoperate with another implementation which 120 does include the option. 122 1.2. Terminology 124 This document uses the following terms: 126 service The NAS provides a service to the dial-in user, such as PPP 127 or Telnet. 129 session Each service provided by the NAS to a dial-in user 131 DRAFT RADIUS Extensions January 1997 133 constitutes a session, with the beginning of the session 134 defined as the point where service is first provided and 135 the end of the session defined as the point where service 136 is ended. A user may have multiple sessions in parallel or 137 series if the NAS supports that, with each session 138 generating a separate start and stop accounting record. 140 silently discard 141 This means the implementation discards the packet without 142 further processing. The implementation SHOULD provide the 143 capability of logging the error, including the contents of 144 the silently discarded packet, and SHOULD record the event 145 in a statistics counter. 147 2. Operation 149 Operation is identical to that defined in RFC 2058 and 2059. 151 2.1. RADIUS support for Apple Remote Access 153 The RADIUS (Remote Authentication Dial-In User Service) protocol 154 provides a method that allows multiple dial-in Network Access Server 155 (NAS) devices to share a common authentication database. 157 The Apple Remote Access Protocol (ARAP) provides a method for sending 158 AppleTalk network traffic over point-to-point links, typically, but 159 not exclusively, asynchronous and ISDN switched-circuit connections. 160 Though Apple is moving toward ATCP on PPP for future remote access 161 services, ARAP is still a common way for the installed base of 162 Macintosh users to make remote network connections, and is likely to 163 remain so for some time. 165 ARAP is supported by several NAS vendors who also support PPP, IPX 166 and other protocols in the same NAS. ARAP connections in these 167 multi-protocol devices are often not authenticated with RADIUS, or if 168 they are, each vendor creates an individual solution to the problem. 170 This section describes the use of additional RADIUS attributes to 171 support ARAP. RADIUS client and server implementations that implement 172 this specification should be able to authenticate ARAP connections in 173 an interoperable manner. 175 This section assumes prior knowledge of RADIUS, and will go into some 176 detail on the operation of ARAP before entering a detailed discussion 177 of the proposed ARAP RADIUS attributes. 179 There are two features of ARAP this document does not address: 181 DRAFT RADIUS Extensions January 1997 183 1. User initiated password changing. This is not part of RADIUS, 184 but can be implemented through a software process other than 185 RADIUS. 187 2. Out-of-Band messages. At any time, the NAS can send messages to 188 an ARA client which appear in a dialog box on the dial-in user's 189 screen. These are not part of authentication and do not belong 190 here. However, we note that a Reply-Message attribute in an 191 Access-Accept may be sent down to the user as a sign-on message of 192 the day string using the out-of-band channel. 194 We have tried to respect the spirit of the existing RADIUS protocol 195 as much as possible, making design decisions compatible with prior 196 art. Further, we have tried to strike a balance between flooding the 197 RADIUS world with new attributes, and hiding all of ARAP operation 198 within a single multiplexed ARAP attribute string or within Extended 199 Authentication Protocol (EAP) [4] machinery. 201 However, we feel ARAP is enough of a departure from PPP to warrant a 202 small set of similarly named attributes of its own. 204 We have assumed that an ARAP-aware RADIUS server will be able to do 205 DES encryption and generate security module challenges. This is in 206 keeping with the general RADIUS goal of smart server / simple NAS. 208 ARAP authenticates a connection in two phases. The first is a "Two- 209 Way DES" random number exchange, using the user's password as a key. 210 We say "Two-Way" because the ARAP NAS challenges the dial-in client 211 to authenticate itself, and the dial-in client challenges the ARAP 212 NAS to authenticate itself. 214 Specifically, ARAP does the following: 216 1. The NAS sends two 32-bit random numbers to the dial-in client 217 in an ARAP msg_auth_challenge packet. 219 2. The dial-in client uses the user's password to DES encrypt the 220 two random numbers sent to it by the NAS. The dial-in client then 221 sends this result, the user's name and two 32-bit random numbers 222 of its own back to the NAS in an ARAP msg_auth_request packet. 224 3. The NAS verifies the encrypted random numbers sent by the 225 dial-in client are what it expected. If so, it encrypts the dial- 226 in client's challenge using the password and sends it back to the 227 dial-in client in an ARAP msg_auth_response packet. 229 Note that if the dial-in client's response was wrong, meaning the 230 user has the wrong password, the server can initiate a retry sequence 232 DRAFT RADIUS Extensions January 1997 234 up to the maximum amount of retries allowed by the NAS. In this case, 235 when the dial-in client receives the ARAP msg_auth_response packet it 236 will acknowledge it with an ARAP msg_auth_again packet. 238 After this first "DES Phase" the ARAP NAS MAY initiate a secondary 239 authentication phase using what Apple calls "Add-In Security 240 Modules." Security Modules are small pieces of code which run on both 241 the client and server and are allowed to read and write arbitrary 242 data across the communications link to perform additional 243 authentication functions. Various security token vendors use this 244 mechanism to authenticate ARA callers. 246 Although ARAP allows security modules to read and write anything they 247 like, all existing security modules use simple challenge and response 248 cycles, with perhaps some overall control information. This document 249 assumes all existing security modules can be supported with one or 250 more challenge/response cycles. 252 To complicate RADIUS and ARAP integration, ARAP sends down some 253 profile information after the DES Phase and before the Security 254 Module phase. This means that besides the responses to challenges, 255 this profile information must also be present, at somewhat unusual 256 times. Fortunately the information is only a few pieces of numeric 257 data related to passwords, which this document packs into a single 258 new attribute. 260 Presenting an Access-Request to RADIUS on behalf of an ARAP 261 connection is straightforward. The ARAP NAS generates the random 262 number challenge, and then receives the dial-in client's response, 263 the dial-in client's challenge, and the user's name. Assuming the 264 user is not a guest, the following information is forwarded in an 265 Access-Request packet: User-Name (up to 31 characters long), Framed- 266 Protocol (set to 3, ARAP), ARAP-Password, and any additional 267 attributes desired, such as Service-Type, NAS-IP-Address, NAS-Id, 268 NAS-Port-Type, NAS-Port, NAS-Port-Id, Connect-Info, etc. 270 The Request Authenticator is a NAS-generated 16 octet random number. 271 The low-order 8 octets of this number are sent to the dial-in user as 272 the two 4 octet random numbers required in the ARAP 273 msg_auth_challenge packet. Octets 0-3 are the first random number and 274 Octets 4-7 are the second random number. [Probably needs to make 275 ordering clearer.] 277 The ARAP-Password in the Access-Request contains a 16 octet random 278 number field, and is used to carry the dial-in user's response to the 279 NAS challenge and the client's own challenge to the NAS. The high- 280 order octets contain the dial-in user's challenge to the NAS (2 32- 281 bit numbers, 8 octets) and the low-order octets contain the dial-in 283 DRAFT RADIUS Extensions January 1997 285 user's response to the NAS challenge (2 32-bit numbers, 8 octets). 287 Only one of User-Password, CHAP-Password, or ARAP-Password needs to 288 be present in an Access-Request, or one or more EAP-Messages. 290 If the RADIUS server does not support ARAP it SHOULD return an 291 Access-Reject to the NAS. 293 If the RADIUS server does support ARAP, it should verify the user's 294 response using the Challenge (from the lower order 8 octets of the 295 Request Authenticator) and the user's response (from the low order 8 296 octets of the ARAP-Password). 298 If that authentication fails, the RADIUS server should return an 299 Access-Reject packet to the NAS, with optional Password-Retry and 300 Reply-Messages attributes. The presence of Password-Retry indicates 301 the ARAP NAS MAY choose to initiate another challenge-response cycle, 302 up to a total number of times equal to the integer value of the 303 Password-Retry attribute. 305 If the user is authenticated, the RADIUS server should return an 306 Access-Accept packet (Code 2) to the NAS, with ID and Response 307 Authenticator as usual, and attributes as follows: 309 Service-Type of Framed-Protocol. 311 Framed-Protocol of ARAP (3). 313 Session-Timeout with the maximum connect time for the user in 314 seconds. If the user is to be given unlimited time, Session- 315 Timeout should not be included in the Access-Accept packet, and 316 ARAP will treat that as an unlimited timeout (-1). 318 ARAP-Challenge-Response, containing 8 octets with the response to 319 the dial-in client's challenge (the high-order 8 octets of the 320 ARAP-Password). 322 ARAP-Features, containing information that the NAS should send to 323 the user in an ARAP "feature flags" packet. 325 Octet 0: If zero, user cannot change their password. If non- 326 zero user can. (RADIUS does not handle the password changing, 327 just the attribute which indicates whether ARAP indicates they 328 can.) 330 Octet 1: Minimum acceptable password length (0-8). 332 Octet 2-5: Password creation date in Macintosh format, defined 334 DRAFT RADIUS Extensions January 1997 336 as 32 bits unsigned representing seconds since Midnight GMT 337 January 1, 1904. 339 Octet 6-9 Password Expiration Delta from create date in 340 seconds. 342 Octet 10-13: Current RADIUS time in Macintosh format 344 Optionally, a single Reply-Message with a string up to 253 345 characters long which MAY be sent down to the user to be displayed 346 in a sign-on/message of the day dialog. 348 Framed-AppleTalk-Network may be included. 350 Framed-AppleTalk-Zone, up to 32 characters in length, may be 351 included. 353 ARAP defines the notion of a list of zones for a user. Along with 354 a list of zone names, a Zone Access Flag is defined (and used by 355 the NAS) which says how to use the list of zone names. That is, 356 the dial-in user may only be allowed to see the Default Zone, or 357 only the zones in the zone list (inclusive) or any zone except 358 those in the zone list (exclusive). 360 The ARAP NAS handles this by having a named filter which contains 361 (at least) zone names. This solves the problem where a single 362 RADIUS server is managing disparate NAS clients who may not be 363 able to "see" all of the zone names in a user zone list. Zone 364 names only have meaning "at the NAS." The disadvantage of this 365 approach is that zone filters must be set up on the NAS somehow, 366 then referenced by the RADIUS Filter-Id. 368 ARAP-Zone-Access contains an integer which specifies how the "zone 369 list" for this user should be used. If this attribute is present 370 and the value is 2 or 4 then a Filter-Id must also be present to 371 name a zone list filter to apply the access flag to. 373 The inclusion of a Callback-Number or Callback-Id attribute in the 374 Access-Accept MAY cause the ARAP NAS to disconnect after sending 375 the Feature Flags to begin callback processing in an ARAP specific 376 way. 378 Other attributes may be present in the Access-Accept packet as well. 380 An ARAP NAS will need other information to finish bringing up the 381 connection to the dial in client, but this information can be 382 provided by the ARAP NAS without any help from RADIUS, either through 383 configuration by SNMP, a NAS administration program, or deduced by 385 DRAFT RADIUS Extensions January 1997 387 the AppleTalk stack in the NAS. Specifically: 389 1. AppearAsNet and AppearAsNode values, sent to the client to tell 390 it what network and node numbers it should use in its datagram 391 packets. AppearAsNet can be taken from the Framed-AppleTalk- 392 Network attribute or from the configuration or AppleTalk stack on 393 the NAS. 395 2. The "default" zone - that is the name of the AppleTalk zone in 396 which the dial-in client will appear. (Or can be specified with 397 the Framed-AppleTalk-Zone attribute.) 399 3. Other very NAS specific stuff such as the name of the NAS, and 400 smartbuffering information. (Smartbuffering is an ARAP mechanism 401 for replacing common AppleTalk datagrams with small tokens, to 402 improve slow link performance in a few common traffic situations.) 404 4. "Zone List" information for this user. The ARAP specification 405 defines a "zone count" field which is actually unused. 407 RADIUS supports ARAP Security Modules in the following manner. 409 After DES authentication has been completed, the RADIUS server may 410 instruct the ARAP NAS to run one or more security modules for the 411 dial-in user. Although the underlying protocol supports executing 412 multiple security modules in series, in practice all current 413 implementations only allow executing one. Through the use of 414 multiple Access-Challenge requests, multiple modules can be 415 supported, but this facility will probably never be used. 417 We also assume that, even though ARAP allows a free-form dialog 418 between security modules on each end of the point-to-point link, in 419 actual practice all security modules can be reduced to a simple 420 challenge/response cycle. 422 If the RADIUS server wishes to instruct the ARAP NAS to run a 423 security module, it should send an Access-Challenge packet to the NAS 424 with (optionally) the State attribute, plus the ARAP-Challenge- 425 Response, ARAP-Features, and two more attributes: 427 ARAP-Security: a four octet security module signature, containing a 428 Macintosh OSType. 430 ARAP-Security-Data, a string to carry the actual security module 431 challenge and response. 433 When the security module finishes executing, the security module 434 response is passed in an ARAP-Security-Data attribute from the NAS 436 DRAFT RADIUS Extensions January 1997 438 to the RADIUS server in a second Access-Request, also including the 439 State from the Access-Challenge. The authenticator field contains no 440 special information in this case, and this can be discerned by the 441 presence of the State attribute. 443 3. Packet Format 445 Packet Format is identical to that defined in RFC 2058 and 2059. 447 4. Packet Types 449 Packet types are identical to those defined in RFC 2058 and 2059. 451 See "Table of Attributes" below to determine which types of packets 452 can contain which attributes defined here. 454 5. Attributes 456 RADIUS Attributes carry the specific authentication, authorization 457 and accounting details for the request and response. 459 Some attributes MAY be included more than once. The effect of this 460 is attribute specific, and is specified in each attribute 461 description. The order of attributes of the same type SHOULD be 462 preserved. The order of attributes of different types is not 463 required to be preserved. 465 The end of the list of attributes is indicated by the Length of the 466 RADIUS packet. 468 A summary of the attribute format is the same as in RFC 2058 but is 469 included here for ease of reference. The fields are transmitted from 470 left to right. 472 0 1 2 473 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Type | Length | Value ... 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 Type 480 The Type field is one octet. Up-to-date values of the RADIUS Type 481 field are specified in the most recent "Assigned Numbers" RFC [2]. 482 Values 192-223 are reserved for experimental use, values 224-240 483 are reserved for implementation-specific use, and values 241-255 484 are reserved and should not be used. This specification concerns 486 DRAFT RADIUS Extensions January 1997 488 the following values: 490 1-39 (refer to RFC 2058, "RADIUS") 491 40-51 (refer to RFC 2059, "RADIUS Accounting") 492 52-59 Unused 493 60-63 (refer to RFC 2058, "RADIUS") 494 64 Prompt 495 65 Connect-Info 496 66 Signature 497 67 EAP-Message 498 68 Configuration-Token 499 69 Password-Retry 500 70 ARAP-Password 501 71 ARAP-Features 502 72 ARAP-Zone-Access 503 73 ARAP-Security 504 74 ARAP-Security-Data 505 75-191 Unused 507 Length 509 The Length field is one octet, and indicates the length of this 510 attribute including the Type, Length and Value fields. If an 511 attribute is received in a packet with an invalid Length, the 512 entire request should be silently discarded. 514 Value 516 The Value field is zero or more octets and contains information 517 specific to the attribute. The format and length of the Value 518 field is determined by the Type and Length fields. 520 The format of the value field is one of four data types. 522 string 0-253 octets 524 address 32 bit value, most significant octet first. 526 integer 32 bit value, most significant octet first. 528 time 32 bit value, most significant octet first -- seconds 529 since 00:00:00 GMT, January 1, 1970. The standard 530 Attributes do not use this data type. 532 DRAFT RADIUS Extensions January 1997 534 5.1. Prompt 536 Description 538 This attribute is used only in Access-Challenge packets, and 539 indicates to the NAS whether it should echo the user's response as 540 it is entered, or not echo it. 542 A summary of the Prompt attribute format is shown below. The fields 543 are transmitted from left to right. 545 0 1 2 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Type | Length | Value 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 Value (cont) | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 Type 555 64 for Prompt. 557 Length 559 6 561 Value 563 The Value field is four octets. 565 0 No Echo 566 1 Echo 568 5.2. Connect-Info 570 Description 572 This attribute is sent from the NAS to indicate the nature of the 573 user's connection. 575 The NAS MAY send this attribute in an Access-Request or 576 Accounting-Request to indicate the nature of the user's 578 DRAFT RADIUS Extensions January 1997 580 connection. 582 A summary of the Connect-Info attribute format is shown below. The 583 fields are transmitted from left to right. 585 0 1 2 586 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Type | Length | String... 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 Type 593 65 for Connect-Info. 595 Length 597 >= 3 599 String 601 The String field is encoded as a ASCII characters with the 602 connection speed at the beginning of the string. 604 For example, "28800 V42BIS/LAPM" 606 5.3. Signature 608 Description 610 This attribute MAY be used to sign Access-Requests to prevent 611 dictionary attacks on CHAP, ARAP or EAP authentication methods. 612 It MAY be used in any Access-Request. 614 A RADIUS Server receiving an Access-Request with a Signature 615 Attribute present SHOULD calculate the correct value of the 616 Signature and silently discard the packet if it does not match the 617 value sent. 619 A summary of the Signature attribute format is shown below. The 620 fields are transmitted from left to right. 622 DRAFT RADIUS Extensions January 1997 624 0 1 2 625 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Type | Length | String... 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 Type 632 66 for Signature. 634 Length 636 18 638 String 640 Signature is an MD-5 [3] checksum of the shared secret followed by 641 the entire Access-Request packet, including Type, ID, Length and 642 authenticator. When the checksum is calculated the signature 643 string should be considered to be sixteen octets of zero. 645 This attribute is not needed if the User-Password attribute is 646 present, but is useful for preventing dictionary attacks on other 647 types of authentication. IP Security will eventually make this 648 attribute unnecessary, so it should be considered an interim 649 measure. 651 5.4. EAP-Message 653 Description 655 This attribute opaquely encodes Extended Access Protocol [4] 656 information to allow dial-in users to use EAP to authenticate 657 without having to implement EAP on the NAS. 659 The NAS places any EAP messages received from the user into one or 660 more EAP attributes and forwards them to the RADIUS Server as part 661 of the Access-Request, which can return EAP messages in Access- 662 Challenge, Access-Accept and Access-Reject packets. 664 A RADIUS Server receiving EAP messages that it does not understand 665 SHOULD return an Access-Reject. 667 A summary of the EAP-Message attribute format is shown below. The 669 DRAFT RADIUS Extensions January 1997 671 fields are transmitted from left to right. 673 0 1 2 674 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | Type | Length | String... 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 Type 681 67 for EAP-Message. 683 Length 685 >= 3. 687 String 689 The String field contains undifferentiated octets. If multiple 690 EAP-Message attributes are present in a packet their values should 691 be concatenated; this allows EAP packets longer than 253 octets to 692 be passed by RADIUS. 694 5.5. Configuration-Token 696 Description 698 This attribute is for use in large distributed authentication 699 networks based on proxy. It is sent from a RADIUS Proxy Server to 700 a RADIUS Proxy Client in an Access-Request to indicate a type of 701 user profile to be used. It should not be sent to a NAS. 703 A summary of the Configuration-Token attribute format is shown below. 704 The fields are transmitted from left to right. 706 0 1 2 707 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Type | Length | String ... 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 Type 714 68 for Configuration-Token. 716 DRAFT RADIUS Extensions January 1997 718 Length 720 >= 3 722 String 724 The String field is one or more octets. The actual format of the 725 information is site or application specific, and a robust 726 implementation SHOULD support the field as undistinguished octets. 728 The codification of the range of allowed usage of this field is 729 outside the scope of this specification. 731 5.6. Password-Retry 733 Description 735 This attribute MAY be included in an Access-Reject to indicate how 736 many authentication attempts a user may be allowed to attempt 737 before being disconnected. 739 It is primarily intended for use with ARAP authentication. 741 A summary of the Password-Retry attribute format is shown below. The 742 fields are transmitted from left to right. 744 0 1 2 3 745 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 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Type | Length | Value 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 Value (cont) | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 Type 754 69 for Password-Retry. 756 Length 758 6 760 Value 762 The Value field is four octets, containing an integer specifying 764 DRAFT RADIUS Extensions January 1997 766 the number of password retry attempts to permit the user. 768 5.7. ARAP-Password 770 Description 772 This attribute is only present in an Access-Request packet 773 containing a Framed-Protocol of ARAP. 775 Only one of User-Password, CHAP-Password, or ARAP-Password needs 776 to be present in an Access-Request, or one or more EAP-Messages. 778 A summary of the ARAP-Password attribute format is shown below. The 779 fields are transmitted from left to right. 781 0 1 2 3 782 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 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | Type | Length | Value1 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | Value2 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | Value3 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | Value4 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 Type 797 70 for ARAP-Password. 799 Length 801 18 803 Value 805 This attribute contains a 16 octet string, used to carry the 806 dial-in user's response to the NAS challenge and the client's own 807 challenge to the NAS. The high-order octets (Value1 and Value2) 808 contain the dial-in user's challenge to the NAS (2 32-bit numbers, 809 8 octets) and the low-order octets (Value3 and Value4) contain the 810 dial-in user's response to the NAS challenge (2 32-bit numbers, 8 811 octets). 813 DRAFT RADIUS Extensions January 1997 815 5.8. ARAP-Features 817 Description 819 This attribute is sent in an Access-Accept packet with Framed- 820 Protocol of ARAP, and includes password information that the NAS 821 should sent to the user in an ARAP "feature flags" packet. 823 A summary of the ARAP-Features attribute format is shown below. The 824 fields are transmitted from left to right. 826 0 1 2 3 827 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 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | Type | Length | Value1 | Value2 | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | Value3 | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | Value4 | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Value5 | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 Type 840 71 for ARAP-Features. 842 Length 844 16 846 Value 848 The Value field is a compound string containing information the 849 NAS should send to the user in the ARAP "feature flags" packet. 851 Value1: If zero, user cannot change their password. If non-zero 852 user can. (RADIUS does not handle the password changing, just 853 the attribute which indicates whether ARAP indicates they can.) 855 Value2: Minimum acceptable password length, from 0 to 8. 857 Value3: Password creation date in Macintosh format, defined as 859 DRAFT RADIUS Extensions January 1997 861 32 unsigned bits representing seconds since Midnight GMT 862 January 1, 1904. 864 Value4: Password Expiration Delta from create date in seconds. 866 Value5: Current RADIUS time in Macintosh format. 868 5.9. ARAP-Zone-Access 870 Description 872 This attribute is included in an Access-Accept packet with 873 Framed-Protocol of ARAP to indicate how the ARAP zone list for the 874 user should be used. 876 A summary of the ARAP-Zone-Access attribute format is shown below. 877 The fields are transmitted from left to right. 879 0 1 2 3 880 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 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | Type | Length | Value 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 Value (cont) | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 Type 889 72 for ARAP-Zone-Access. 891 Length 893 6 895 Value 897 The Value field is four octets encoding an integer with one of the 898 following values: 900 1 Only allow access to default zone 901 2 Use zone filter inclusively 902 4 Use zone filter exclusively 904 The value 3 is skipped, not because these are bit flags, but 906 DRAFT RADIUS Extensions January 1997 908 because 3 in some ARAP implementations means "all zones" which is 909 the same as not specifying a list at all under RADIUS. 911 If this attribute is present and the value is 2 or 4 then a 912 Filter-Id must also be present to name a zone list filter to apply 913 the access flag to. 915 5.10. ARAP-Security 917 Description 919 This attribute identifies the ARAP Security Module to be used in 920 an Access-Challenge packet. 922 A summary of the ARAP-Security attribute format is shown below. The 923 fields are transmitted from left to right. 925 0 1 2 3 926 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 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | Type | Length | Value 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 Value (cont) | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 Type 935 73 for ARAP-Security. 937 Length 939 6 941 Value 943 The Value field is four octets, containing an integer specifying 944 the security module signature, which is a Macintosh OSType. 945 (Macintosh OSTypes are 4 ascii characters cast as a 32-bit 946 integer) 948 5.11. ARAP-Security-Data 950 Description 952 DRAFT RADIUS Extensions January 1997 954 This attribute contains the actual security module challenge or 955 response, and can be found in Access-Challenge and Access-Request 956 packets. 958 A summary of the ARAP-Security-Data attribute format is shown below. 959 The fields are transmitted from left to right. 961 0 1 2 962 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | Type | Length | String... 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 Type 969 74 for ARAP-Security-Data. 971 Length 973 >=3 975 String 977 The String field contains the security module challenge or 978 response associated with the ARAP Security Module specified in 979 ARAP-Security. 981 5.12. Table of Attributes 983 The following table provides a guide to which attributes may be found 984 in which kind of packets. Connect-Info may have 0-1 instances in an 985 Accounting-Request packet, the other attributes added in this 986 document must not be present in an Accounting-Request. 988 Request Accept Reject Challenge # Attribute 989 0 0 0 0-1 64 Prompt 990 0-1 0 0 0 65 Connect-Info 991 0-1 0 0 0 66 Signature 992 0+ 0+ 0+ 0+ 67 EAP-Message [Note 1] 993 0 0+ 0 0 68 Configuration-Token 994 0 0 0-1 0 69 Password-Retry 995 0-1 0 0 0 70 ARAP-Password [Note 1] 996 0 0-1 0 0-1 71 ARAP-Features 997 0 0-1 0 0 72 ARAP-Zone-Access 999 DRAFT RADIUS Extensions January 1997 1001 0-1 0 0 0-1 73 ARAP-Security 1002 0+ 0 0 0+ 73 ARAP-Security-Data 1003 Request Accept Reject Challenge # Attribute 1005 [Note 1] An Access-Request MUST contain either a User-Password or 1006 CHAP-Password or ARAP-Password or one or more EAP-Messages, and MUST 1007 NOT contain more than one type of those four attributes. 1009 The following table defines the above table entries. 1011 0 This attribute MUST NOT be present 1012 0+ Zero or more instances of this attribute MAY be present. 1013 0-1 Zero or one instance of this attribute MAY be present. 1014 1 Exactly one instance of this attribute MUST be present. 1016 Security Considerations 1018 Security issues are the primary topic of this document. 1020 References 1022 [1] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote 1023 Authentication Dial In User Service (RADIUS)", RFC 2058, 1024 January 1997. 1026 [2] Rigney, C., "RADIUS Accounting", RFC 2059, January 1997. 1028 [3] Rivest, R., and Dusse, S., "The MD5 Message-Digest Algorithm", 1029 RFC 1321, MIT Laboratory for Computer Science, RSA Data 1030 Security Inc., April 1992. 1032 [4] Blunk, L., and Vollbrecht, J., "PPP Extensible Authentication 1033 Protocol (EAP)", draft-ietf-pppext-eap-auth-02.txt, June 1996. 1035 Acknowledgments 1037 RADIUS and RADIUS Accounting were originally developed by Livingston 1038 Enterprises for their PortMaster series of Network Access Servers. 1040 The section on ARAP is adopted with permission from "Using RADIUS to 1041 Authenticate Apple Remote Access Connections" by Ward Willats of Cyno 1042 Technologies (ward@cyno.com). 1044 DRAFT RADIUS Extensions January 1997 1046 Chair's Address 1048 The RADIUS working group can be contacted via the current chair: 1050 Carl Rigney 1051 Livingston Enterprises 1052 4464 Willow Road 1053 Pleasanton, California 94588 1055 Phone: +1 510 426 0770 1056 E-Mail: cdr@livingston.com 1058 Author's Addresses 1060 Questions about this memo can also be directed to: 1062 Carl Rigney 1063 Livingston Enterprises 1064 4464 Willow Road 1065 Pleasanton, California 94566 1067 E-Mail: cdr@livingston.com 1069 Questions on ARAP and RADIUS may be directed to: 1071 Ward Willats 1072 Cyno Technologies 1073 1082 Glen Echo Ave 1074 San Jose, CA 95125 1076 Phone: +1 408 297 7766 1077 Email: ward@cyno.com