Network Working Group
`Request for Comments: 2138
`Obsoletes: 2058
`Category: Standards Track
`
`C. Rigney
`Livingston
`A. Rubens
`Merit
`W. Simpson
`Daydreamer
`S. Willens
`Livingston
`April 1997
`
`Remote Authentication Dial In User Service (RADIUS)
`
`Status of this Memo
`
` This document specifies an Internet standards track protocol for the
` Internet community, and requests discussion and suggestions for
` improvements. Please refer to the current edition of the "Internet
` Official Protocol Standards" (STD 1) for the standardization state
` and status of this protocol. Distribution of this memo is unlimited.
`
`Abstract
`
` This document describes a protocol for carrying authentication,
` authorization, and configuration information between a Network Access
` Server which desires to authenticate its links and a shared
` Authentication Server.
`
`Implementation Note
`
` This memo documents the RADIUS protocol. There has been some
` confusion in the assignment of port numbers for this protocol. The
` early deployment of RADIUS was done using the erroneously chosen port
` number 1645, which conflicts with the "datametrics" service. The
` officially assigned port number for RADIUS is 1812.
`
`Table of Contents
`
`1.
`
`2.
`
`3.
`4.
`
`Introduction .......................................... 3
`Specification of Requirements ................... 4
`Terminology ..................................... 5
`Operation ............................................. 5
`Challenge/Response .............................. 7
`Interoperation with PAP and CHAP ................ 7
`Why UDP? ........................................ 8
`Packet Format ......................................... 10
`Packet Types .......................................... 13
`Access-Request .................................. 13
`
`1.1
`1.2
`
`2.1
`2.2
`2.3
`
`4.1
`
`Rigney, et. al.
`
`Standards Track
`
`[Page 1]
`
`Ex.1021
`APPLE INC. / Page 1 of 65
`
`

`

`RFC 2138 RADIUS April 1997
`
` 4.2 Access-Accept ................................... 14
` 4.3 Access-Reject ................................... 15
` 4.4 Access-Challenge ................................ 17
` 5. Attributes ............................................ 18
` 5.1 User-Name ....................................... 21
` 5.2 User-Password ................................... 22
` 5.3 CHAP-Password ................................... 23
` 5.4 NAS-IP-Address .................................. 24
` 5.5 NAS-Port ........................................ 25
` 5.6 Service-Type .................................... 26
` 5.7 Framed-Protocol ................................. 28
` 5.8 Framed-IP-Address ............................... 29
` 5.9 Framed-IP-Netmask ............................... 29
` 5.10 Framed-Routing .................................. 30
` 5.11 Filter-Id ....................................... 31
` 5.12 Framed-MTU ...................................... 32
` 5.13 Framed-Compression .............................. 33
` 5.14 Login-IP-Host ................................... 33
` 5.15 Login-Service ................................... 34
` 5.16 Login-TCP-Port .................................. 35
` 5.17 (unassigned) .................................... 36
` 5.18 Reply-Message ................................... 36
` 5.19 Callback-Number ................................. 37
` 5.20 Callback-Id ..................................... 38
` 5.21 (unassigned) .................................... 38
` 5.22 Framed-Route .................................... 39
` 5.23 Framed-IPX-Network .............................. 40
` 5.24 State ........................................... 40
` 5.25 Class ........................................... 41
` 5.26 Vendor-Specific ................................. 42
` 5.27 Session-Timeout ................................. 44
` 5.28 Idle-Timeout .................................... 44
` 5.29 Termination-Action .............................. 45
` 5.30 Called-Station-Id ............................... 46
` 5.31 Calling-Station-Id .............................. 47
` 5.32 NAS-Identifier .................................. 48
` 5.33 Proxy-State ..................................... 48
` 5.34 Login-LAT-Service ............................... 49
` 5.35 Login-LAT-Node .................................. 50
` 5.36 Login-LAT-Group ................................. 51
` 5.37 Framed-AppleTalk-Link ........................... 52
` 5.38 Framed-AppleTalk-Network ........................ 53
` 5.39 Framed-AppleTalk-Zone ........................... 54
` 5.40 CHAP-Challenge .................................. 55
` 5.41 NAS-Port-Type ................................... 55
` 5.42 Port-Limit ...................................... 56
` 5.43 Login-LAT-Port .................................. 57
` 5.44 Table of Attributes ............................. 58
`
`Rigney, et. al. Standards Track [Page 2]
`
`Ex.1021
`APPLE INC. / Page 2 of 65
`
`

`

`RFC 2138 RADIUS April 1997
`
` 6. Examples .............................................. 59
` 6.1 User Telnet to Specified Host ................... 60
` 6.2 Framed User Authenticating with CHAP ............ 60
` 6.3 User with Challenge-Response card ............... 61
` Security Considerations ...................................... 63
` References ................................................... 64
` Acknowledgements ............................................. 64
` Chair’s Address .............................................. 65
` Author’s Addresses ........................................... 65
`
`1. Introduction
`
` Managing dispersed serial line and modem pools for large numbers of
` users can create the need for significant administrative support.
` Since modem pools are by definition a link to the outside world, they
` require careful attention to security, authorization and accounting.
` This can be best achieved by managing a single "database" of users,
` which allows for authentication (verifying user name and password) as
` well as configuration information detailing the type of service to
` deliver to the user (for example, SLIP, PPP, telnet, rlogin).
`
` Key features of RADIUS are:
`
` Client/Server Model
`
` A Network Access Server (NAS) operates as a client of RADIUS. The
` client is responsible for passing user information to designated
` RADIUS servers, and then acting on the response which is returned.
`
` RADIUS servers are responsible for receiving user connection
` requests, authenticating the user, and then returning all
` configuration information necessary for the client to deliver
` service to the user.
`
` A RADIUS server can act as a proxy client to other RADIUS servers
` or other kinds of authentication servers.
`
` Network Security
`
` Transactions between the client and RADIUS server are
` authenticated through the use of a shared secret, which is never
` sent over the network. In addition, any user passwords are sent
` encrypted between the client and RADIUS server, to eliminate the
` possibility that someone snooping on an unsecure network could
` determine a user’s password.
`
`Rigney, et. al. Standards Track [Page 3]
`
`Ex.1021
`APPLE INC. / Page 3 of 65
`
`

`

`RFC 2138 RADIUS April 1997
`
` Flexible Authentication Mechanisms
`
` The RADIUS server can support a variety of methods to authenticate
` a user. When it is provided with the user name and original
` password given by the user, it can support PPP PAP or CHAP, UNIX
` login, and other authentication mechanisms.
`
` Extensible Protocol
`
` All transactions are comprised of variable length Attribute-
` Length-Value 3-tuples. New attribute values can be added without
` disturbing existing implementations of the protocol.
`
`1.1. Specification of Requirements
`
` In this document, several words are used to signify the requirements
` of the specification. These words are often capitalized.
`
` MUST This word, or the adjective "required", means that the
` definition is an absolute requirement of the specification.
`
` MUST NOT This phrase means that the definition is an absolute
` prohibition of the specification.
`
` SHOULD This word, or the adjective "recommended", means that there
` may exist valid reasons in particular circumstances to
` ignore this item, but the full implications must be
` understood and carefully weighed before choosing a
` different course.
`
` MAY This word, or the adjective "optional", means that this
` item is one of an allowed set of alternatives. An
` implementation which does not include this option MUST be
` prepared to interoperate with another implementation which
` does include the option.
`
`Rigney, et. al. Standards Track [Page 4]
`
`Ex.1021
`APPLE INC. / Page 4 of 65
`
`

`

`RFC 2138 RADIUS April 1997
`
`1.2. Terminology
`
` This document frequently uses the following terms:
`
` service The NAS provides a service to the dial-in user, such as PPP
` or Telnet.
`
` session Each service provided by the NAS to a dial-in user
` constitutes a session, with the beginning of the session
` defined as the point where service is first provided and
` the end of the session defined as the point where service
` is ended. A user may have multiple sessions in parallel or
` series if the NAS supports that.
`
` silently discard
` This means the implementation discards the packet without
` further processing. The implementation SHOULD provide the
` capability of logging the error, including the contents of
` the silently discarded packet, and SHOULD record the event
` in a statistics counter.
`
`2. Operation
`
` When a client is configured to use RADIUS, any user of the client
` presents authentication information to the client. This might be
` with a customizable login prompt, where the user is expected to enter
` their username and password. Alternatively, the user might use a
` link framing protocol such as the Point-to-Point Protocol (PPP),
` which has authentication packets which carry this information.
`
` Once the client has obtained such information, it may choose to
` authenticate using RADIUS. To do so, the client creates an "Access-
` Request" containing such Attributes as the user’s name, the user’s
` password, the ID of the client and the Port ID which the user is
` accessing. When a password is present, it is hidden using a method
` based on the RSA Message Digest Algorithm MD5 [1].
`
` The Access-Request is submitted to the RADIUS server via the network.
` If no response is returned within a length of time, the request is
` re-sent a number of times. The client can also forward requests to
` an alternate server or servers in the event that the primary server
` is down or unreachable. An alternate server can be used either after
` a number of tries to the primary server fail, or in a round-robin
` fashion. Retry and fallback algorithms are the topic of current
` research and are not specified in detail in this document.
`
`Rigney, et. al. Standards Track [Page 5]
`
`Ex.1021
`APPLE INC. / Page 5 of 65
`
`

`

`RFC 2138 RADIUS April 1997
`
` Once the RADIUS server receives the request, it validates the sending
` client. A request from a client for which the RADIUS server does not
` have a shared secret should be silently discarded. If the client is
` valid, the RADIUS server consults a database of users to find the
` user whose name matches the request. The user entry in the database
` contains a list of requirements which must be met to allow access for
` the user. This always includes verification of the password, but can
` also specify the client(s) or port(s) to which the user is allowed
` access.
`
` The RADIUS server MAY make requests of other servers in order to
` satisfy the request, in which case it acts as a client.
`
` If any condition is not met, the RADIUS server sends an "Access-
` Reject" response indicating that this user request is invalid. If
` desired, the server MAY include a text message in the Access-Reject
` which MAY be displayed by the client to the user. No other
` Attributes are permitted in an Access-Reject.
`
` If all conditions are met and the RADIUS server wishes to issue a
` challenge to which the user must respond, the RADIUS server sends an
` "Access-Challenge" response. It MAY include a text message to be
` displayed by the client to the user prompting for a response to the
` challenge, and MAY include a State attribute. If the client receives
` an Access-Challenge and supports challenge/response it MAY display
` the text message, if any, to the user, and then prompt the user for a
` response. The client then re-submits its original Access-Request
` with a new request ID, with the User-Password Attribute replaced by
` the response (encrypted), and including the State Attribute from the
` Access-Challenge, if any. Only 0 or 1 instances of the State
` Attributes should be present in a request. The server can respond to
` this new Access-Request with either an Access-Accept, an Access-
` Reject, or another Access-Challenge.
`
` If all conditions are met, the list of configuration values for the
` user are placed into an "Access-Accept" response. These values
` include the type of service (for example: SLIP, PPP, Login User) and
` all necessary values to deliver the desired service. For SLIP and
` PPP, this may include values such as IP address, subnet mask, MTU,
` desired compression, and desired packet filter identifiers. For
` character mode users, this may include values such as desired
` protocol and host.
`
`Rigney, et. al. Standards Track [Page 6]
`
`Ex.1021
`APPLE INC. / Page 6 of 65
`
`

`

`RFC 2138 RADIUS April 1997
`
`2.1. Challenge/Response
`
` In challenge/response authentication, the user is given an
` unpredictable number and challenged to encrypt it and give back the
` result. Authorized users are equipped with special devices such as
` smart cards or software that facilitate calculation of the correct
` response with ease. Unauthorized users, lacking the appropriate
` device or software and lacking knowledge of the secret key necessary
` to emulate such a device or software, can only guess at the response.
`
` The Access-Challenge packet typically contains a Reply-Message
` including a challenge to be displayed to the user, such as a numeric
` value unlikely ever to be repeated. Typically this is obtained from
` an external server that knows what type of authenticator should be in
` the possession of the authorized user and can therefore choose a
` random or non-repeating pseudorandom number of an appropriate radix
` and length.
`
` The user then enters the challenge into his device (or software) and
` it calculates a response, which the user enters into the client which
` forwards it to the RADIUS server via a second Access-Request. If the
` response matches the expected response the RADIUS server replies with
` an Access-Accept, otherwise an Access-Reject.
`
` Example: The NAS sends an Access-Request packet to the RADIUS Server
` with NAS-Identifier, NAS-Port, User-Name, User-Password (which may
` just be a fixed string like "challenge" or ignored). The server
` sends back an Access-Challenge packet with State and a Reply-Message
` along the lines of "Challenge 12345678, enter your response at the
` prompt" which the NAS displays. The NAS prompts for the response and
` sends a NEW Access-Request to the server (with a new ID) with NAS-
` Identifier, NAS-Port, User-Name, User-Password (the response just
` entered by the user, encrypted), and the same State Attribute that
` came with the Access-Challenge. The server then sends back either an
` Access-Accept or Access-Reject based on whether the response matches
` what it should be, or it can even send another Access-Challenge.
`
`2.2. Interoperation with PAP and CHAP
`
` For PAP, the NAS takes the PAP ID and password and sends them in an
` Access-Request packet as the User-Name and User-Password. The NAS MAY
` include the Attributes Service-Type = Framed-User and Framed-Protocol
` = PPP as a hint to the RADIUS server that PPP service is expected.
`
` For CHAP, the NAS generates a random challenge (preferably 16 octets)
` and sends it to the user, who returns a CHAP response along with a
` CHAP ID and CHAP username. The NAS then sends an Access-Request
` packet to the RADIUS server with the CHAP username as the User-Name
`
`Rigney, et. al. Standards Track [Page 7]
`
`Ex.1021
`APPLE INC. / Page 7 of 65
`
`

`

`RFC 2138 RADIUS April 1997
`
` and with the CHAP ID and CHAP response as the CHAP-Password
` (Attribute 3). The random challenge can either be included in the
` CHAP-Challenge attribute or, if it is 16 octets long, it can be
` placed in the Request Authenticator field of the Access-Request
` packet. The NAS MAY include the Attributes Service-Type = Framed-
` User and Framed-Protocol = PPP as a hint to the RADIUS server that
` PPP service is expected.
`
` The RADIUS server looks up a password based on the User-Name,
` encrypts the challenge using MD5 on the CHAP ID octet, that password,
` and the CHAP challenge (from the CHAP-Challenge attribute if present,
` otherwise from the Request Authenticator), and compares that result
` to the CHAP-Password. If they match, the server sends back an
` Access-Accept, otherwise it sends back an Access-Reject.
`
` If the RADIUS server is unable to perform the requested
` authentication it should return an Access-Reject. For example, CHAP
` requires that the user’s password be available in cleartext to the
` server so that it can encrypt the CHAP challenge and compare that to
` the CHAP response. If the password is not available in cleartext to
` the RADIUS server then the server MUST send an Access-Reject to the
` client.
`
`2.3. Why UDP?
`
` A frequently asked question is why RADIUS uses UDP instead of TCP as
` a transport protocol. UDP was chosen for strictly technical reasons.
`
` There are a number of issues which must be understood. RADIUS is a
` transaction based protocol which has several interesting
` characteristics:
`
` 1. If the request to a primary Authentication server fails, a
` secondary server must be queried.
`
` To meet this requirement, a copy of the request must be kept
` above the transport layer to allow for alternate transmission.
` This means that retransmission timers are still required.
`
` 2. The timing requirements of this particular protocol are
` significantly different than TCP provides.
`
` At one extreme, RADIUS does not require a "responsive"
` detection of lost data. The user is willing to wait several
` seconds for the authentication to complete. The generally
` aggressive TCP retransmission (based on average round trip
` time) is not required, nor is the acknowledgement overhead of
` TCP.
`
`Rigney, et. al. Standards Track [Page 8]
`
`Ex.1021
`APPLE INC. / Page 8 of 65
`
`

`

`RFC 2138 RADIUS April 1997
`
` At the other extreme, the user is not willing to wait several
` minutes for authentication. Therefore the reliable delivery of
` TCP data two minutes later is not useful. The faster use of an
` alternate server allows the user to gain access before giving
` up.
`
` 3. The stateless nature of this protocol simplifies the use of UDP.
`
` Clients and servers come and go. Systems are rebooted, or are
` power cycled independently. Generally this does not cause a
` problem and with creative timeouts and detection of lost TCP
` connections, code can be written to handle anomalous events.
` UDP however completely eliminates any of this special handling.
` Each client and server can open their UDP transport just once
` and leave it open through all types of failure events on the
` network.
`
` 4. UDP simplifies the server implementation.
`
` In the earliest implementations of RADIUS, the server was
` single threaded. This means that a single request was
` received, processed, and returned. This was found to be
` unmanageable in environments where the back-end security
` mechanism took real time (1 or more seconds). The server
` request queue would fill and in environments where hundreds of
` people were being authenticated every minute, the request
` turn-around time increased to longer that users were willing to
` wait (this was especially severe when a specific lookup in a
` database or over DNS took 30 or more seconds). The obvious
` solution was to make the server multi-threaded. Achieving this
` was simple with UDP. Separate processes were spawned to serve
` each request and these processes could respond directly to the
` client NAS with a simple UDP packet to the original transport
` of the client.
`
` It’s not all a panacea. As noted, using UDP requires one thing
` which is built into TCP: with UDP we must artificially manage
` retransmission timers to the same server, although they don’t
` require the same attention to timing provided by TCP. This one
` penalty is a small price to pay for the advantages of UDP in
` this protocol.
`
` Without TCP we would still probably be using tin cans connected
` by string. But for this particular protocol, UDP is a better
` choice.
`
`Rigney, et. al. Standards Track [Page 9]
`
`Ex.1021
`APPLE INC. / Page 9 of 65
`
`

`

`RFC 2138 RADIUS April 1997
`
`3. Packet Format
`
` Exactly one RADIUS packet is encapsulated in the UDP Data field [2],
` where the UDP Destination Port field indicates 1812 (decimal).
`
` When a reply is generated, the source and destination ports are
` reversed.
`
` This memo documents the RADIUS protocol. There has been some
` confusion in the assignment of port numbers for this protocol. The
` early deployment of RADIUS was done using the erroneously chosen port
` number 1645, which conflicts with the "datametrics" service. The
` officially assigned port number for RADIUS is 1812.
`
` A summary of the RADIUS data format is shown below. The fields are
` transmitted from left to right.
`
` 0 1 2 3
` 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
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Code | Identifier | Length |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | |
` | Authenticator |
` | |
` | |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Attributes ...
` +-+-+-+-+-+-+-+-+-+-+-+-+-
`
`Code
`
` The Code field is one octet, and identifies the type of RADIUS
` packet. When a packet is received with an invalid Code field, it is
` silently discarded.
`
` RADIUS Codes (decimal) are assigned as follows:
`
` 1 Access-Request
` 2 Access-Accept
` 3 Access-Reject
` 4 Accounting-Request
` 5 Accounting-Response
` 11 Access-Challenge
` 12 Status-Server (experimental)
` 13 Status-Client (experimental)
` 255 Reserved
`
`Rigney, et. al. Standards Track [Page 10]
`
`Ex.1021
`APPLE INC. / Page 10 of 65
`
`

`

`RFC 2138 RADIUS April 1997
`
` Codes 4 and 5 are covered in the RADIUS Accounting document [9], and
` are not further mentioned here. Codes 12 and 13 are reserved for
` possible use, but are not further mentioned here.
`
`Identifier
`
` The Identifier field is one octet, and aids in matching requests and
` replies.
`
`Length
`
` The Length field is two octets. It indicates the length of the
` packet including the Code, Identifier, Length, Authenticator and
` Attribute fields. Octets outside the range of the Length field
` should be treated as padding and should be ignored on reception. If
` the packet is shorter than the Length field indicates, it should be
` silently discarded. The minimum length is 20 and maximum length is
` 4096.
`
`Authenticator
`
` The Authenticator field is sixteen (16) octets. The most significant
` octet is transmitted first. This value is used to authenticate the
` reply from the RADIUS server, and is used in the password hiding
` algorithm.
`
`Request Authenticator
`
` In Access-Request Packets, the Authenticator value is a 16 octet
` random number, called the Request Authenticator. The value SHOULD
` be unpredictable and unique over the lifetime of a secret (the
` password shared between the client and the RADIUS server), since
` repetition of a request value in conjunction with the same secret
` would permit an attacker to reply with a previously intercepted
` response. Since it is expected that the same secret MAY be used
` to authenticate with servers in disparate geographic regions, the
` Request Authenticator field SHOULD exhibit global and temporal
` uniqueness.
`
` The Request Authenticator value in an Access-Request packet SHOULD
` also be unpredictable, lest an attacker trick a server into
` responding to a predicted future request, and then use the
` response to masquerade as that server to a future Access-Request.
`
`Rigney, et. al. Standards Track [Page 11]
`
`Ex.1021
`APPLE INC. / Page 11 of 65
`
`

`

`RFC 2138 RADIUS April 1997
`
` Although protocols such as RADIUS are incapable of protecting
` against theft of an authenticated session via realtime active
` wiretapping attacks, generation of unique unpredictable requests
` can protect against a wide range of active attacks against
` authentication.
`
` The NAS and RADIUS server share a secret. That shared secret
` followed by the Request Authenticator is put through a one-way MD5
` hash to create a 16 octet digest value which is xored with the
` password entered by the user, and the xored result placed in the
` User-Password attribute in the Access-Request packet. See the
` entry for User-Password in the section on Attributes for a more
` detailed description.
`
` Response Authenticator
`
` The value of the Authenticator field in Access-Accept, Access-
` Reject, and Access-Challenge packets is called the Response
` Authenticator, and contains a one-way MD5 hash calculated over a
` stream of octets consisting of: the RADIUS packet, beginning with
` the Code field, including the Identifier, the Length, the Request
` Authenticator field from the Access-Request packet, and the
` response Attributes, followed by the shared secret. That is,
` ResponseAuth = MD5(Code+ID+Length+RequestAuth+Attributes+Secret)
` where + denotes concatenation.
`
`Administrative Note
`
` The secret (password shared between the client and the RADIUS server)
` SHOULD be at least as large and unguessable as a well-chosen
` password. It is preferred that the secret be at least 16 octets.
` This is to ensure a sufficiently large range for the secret to
` provide protection against exhaustive search attacks. A RADIUS
` server SHOULD use the source IP address of the RADIUS UDP packet to
` decide which shared secret to use, so that RADIUS requests can be
` proxied.
`
` When using a forwarding proxy, the proxy must be able to alter the
` packet as it passes through in each direction - when the proxy
` forwards the request, the proxy can add a Proxy-State Attribute, and
` when the proxy forwards a response, it removes the Proxy-State
` Attribute. Since Access-Accept and Access-Reject replies are
` authenticated on the entire packet contents, the stripping of the
` Proxy-State attribute would invalidate the signature in the packet -
` so the proxy has to re-sign it.
`
` Further details of RADIUS proxy implementation are outside the scope
` of this document.
`
`Rigney, et. al. Standards Track [Page 12]
`
`Ex.1021
`APPLE INC. / Page 12 of 65
`
`

`

`RFC 2138 RADIUS April 1997
`
`Attributes
`
` Many Attributes may have multiple instances, in such a case the order
` of Attributes of the same Type SHOULD be preserved. The order of
` Attributes of different Types is not required to be preserved.
`
` In the section below on "Attributes" where the text refers to which
` packets an attribute is allowed in, only packets with Codes 1, 2, 3
` and 11 and attributes defined in this document are covered in this
` document. A summary table is provided at the end of the "Attributes"
` section. To determine which Attributes are allowed in packets with
` codes 4 and 5 refer to the RADIUS Accounting document [9].
`
`4. Packet Types
`
` The RADIUS Packet type is determined by the Code field in the first
` octet of the Packet.
`
`4.1. Access-Request
`
` Description
`
` Access-Request packets are sent to a RADIUS server, and convey
` information used to determine whether a user is allowed access to
` a specific NAS, and any special services requested for that user.
` An implementation wishing to authenticate a user MUST transmit a
` RADIUS packet with the Code field set to 1 (Access-Request).
`
` Upon receipt of an Access-Request from a valid client, an
` appropriate reply MUST be transmitted.
`
` An Access-Request MUST contain a User-Name attribute. It SHOULD
` contain either a NAS-IP-Address attribute or NAS-Identifier
` attribute (or both, although that is not recommended). It MUST
` contain either a User-Password attribute or CHAP-Password
` attribute. It SHOULD contain a NAS-Port or NAS-Port-Type
` attribute or both unless the type of access being requested does
` not involve a port or the NAS does not distinguish among its
` ports.
`
` An Access-Request MAY contain additional attributes as a hint to
` the server, but the server is not required to honor the hint.
`
` When a User-Password is present, it is hidden using a method based
` on the RSA Message Digest Algorithm MD5 [1].
`
` A summary of the Access-Request packet format is shown below. The
` fields are transmitted from left to right.
`
`Rigney, et. al. Standards Track [Page 13]
`
`Ex.1021
`APPLE INC. / Page 13 of 65
`
`

`

`RFC 2138 RADIUS April 1997
`
` 0 1 2 3
` 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
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Code | Identifier | Length |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` |