INTERNET DRAFT Pat R. Calhoun
Category: Standards Track Sun Microsystems, Inc.
Title: draft-calhoun-diameter-eap-01.txt Allan Rubens
Date: March 1998 Merit Networks Inc.
Bernard Aboba
Microsoft Corporation
DIAMETER
Extensible Authentication Protocol Extensions
<draft-calhoun-diameter-eap-01.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months.
Internet-Drafts may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet-Drafts
as reference material or to cite them other than as a ``working
draft'' or ``work in progress.''
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or
munnari.oz.au.
Abstract
The Extensible Authentication Protocol (EAP) is a PPP extension that
provides support for additional authentication methods within PPP.
This document describes how the EAP-Message and Signature attributes
may be used for providing EAP support within DIAMETER.
Table of Contents
1.0 Introduction
1.1 Definitions
2.0 Protocol overview
2.1 Example of an OTP Authentication
2.2 NAS Initiated EAP Authentication
2.3 Example of failed EAP Authentication
2.4 Example of DIAMETER not supporting EAP
2.5 Example of DIAMETER Proxy not supporting EAP
Calhoun, Rubens, Aboba expires September 1998 [Page 1]
INTERNET DRAFT March 1998
2.6 Example of PPP Client not supporting EAP
3.0 Alternative uses
4.0 Command Name and Command Code
5.0 Command Meanings
5.1 DIAMETER-EAP-Request
5.2 DIAMETER-EAP-Response
5.3 DIAMETER-EAP-Ack
5.4 DIAMETER-EAP-Reject
6.0 Attribute Name and Attribute Code
7.0 Attribute Meanings
7.1 EAP-Packet
8.0 Acknowledgments
9.0 References
10.0 Authors' Addresses
1.0 Introduction
The Extensible Authentication Protocol (EAP), described in [1],
provides a standard mechanism for support of additional authentication
methods within PPP. Through the use of EAP, support for a number of
authentication schemes may be added, including token cards, Kerberos,
Public Key, One Time Passwords, and others. In order to provide for
support of EAP within DIAMETER, two new attributes, EAP-Message and
Signature, were introduced as DIAMETER extensions in [5]. This
document describes how these new attributes may be used for providing
EAP support within DIAMETER.
The scheme described here is similar to that proposed in [2], in that
the DIAMETER server is used to shuttle DIAMETER-encapsulated EAP
Packets between the NAS and a backend security server. While the
conversation between the DIAMETER server and the backend security
server will typically occur using a proprietary protocol developed by
the backend security server vendor, it is also possible to use
DIAMETER-encapsulated EAP via the EAP-Message attribute. This has the
advantage of allowing the DIAMETER server to support EAP without the
need for authentication- specific code, which can instead reside on a
backend security server.
This original document was named Enhanced RADIUS and was changed at
the request of the WG since this protocol is different from the
former.
This document describes a management protocol used between Network
Access Servers and DIAMETER Servers for authentication, authorization,
and accounting of dial-up users. A considerable amount of effort was
put into the design of this protocol to ensure that an implementation
could support both DIAMETER and RADIUS at the same time.
Calhoun, Rubens, Aboba expires September 1998 [Page 2]
INTERNET DRAFT March 1998
Calhoun, Rubens, Aboba expires September 1998 [Page 3]
INTERNET DRAFT March 1998
1.1 Definitions
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.
2.0 Protocol overview
The EAP conversation between the authenticating peer and the NAS
begins with the negotiation of EAP within LCP. Once EAP has been
negotiated, the NAS will typically send to the DIAMETER server a
DIAMETER Message packet containing the DIAMETER-EAP-Request Command
signifying an EAP-Start. EAP-Start is indicated by sending an
DIAMETER-EAP-Request Command with an EAP-Packet attribute with a
length of 7 (no data). The Port number and NAS Identifier MUST be
included in the attributes issued by the NAS in the DIAMETER-EAP-
Request packet.
If the DIAMETER server supports EAP, it MUST respond with an DIAMETER-
EAP-Response packet containing an EAP-Packet attribute. The EAP-Packet
attribute includes an encapsulated EAP packet which is then passed on
to the authenticating peer. The DIAMETER-EAP-Response typically will
contain an EAP-Packet attribute encapsulating an EAP-Request/Identity
message, requesting the authenticating peer to identify itself. The
NAS will then respond with a DIAMETER-EAP-Request packet containing an
EAP-Packet attribute encapsulating an EAP-Response, etc. The
conversation continues until either a DIAMETER-EAP-Reject packet is
received (with an EAP-Packet attribute encapsulating EAP-Failure)
which results in the NAS disconnecting the user, or a DIAMETER-EAP-Ack
packet is received (with an EAP-Packet attribute encapsulating EAP-
Success) successfully ending the authentication phase. Note that if a
Calhoun, Rubens, Aboba expires September 1998 [Page 4]
INTERNET DRAFT March 1998
DIAMETER-EAP-Reject packet with an EAP-Packet attribute encapsulating
EAP-Failure is received from the DIAMETER Server, the NAS SHOULD issue
an LCP Terminate Request to the authenticating peer.
The above scenario creates a situation in which the NAS never needs to
manipulate an EAP packet. An alternative may be used in situations
where an EAP-Request/Identity message will always be sent by the NAS
to the authenticating peer. This involves having the NAS send an EAP-
Request/Identity message to the authenticating peer, and forwarding
the EAP-Response/Identity packet to the DIAMETER server in the EAP-
Packet attribute of a DIAMETER-EAP-Request packet. While this approach
will save a round-trip, it cannot be universally employed. There are
circumstances in which the user's identity may not be needed (such as
when authentication and accounting is handled based on the calling or
called phone number), and therefore an EAP-Request/Identity packet may
not necessarily be issued by the NAS to the authenticating peer.
Unless the NAS interprets the EAP-Response/Identity packet returned by
the authenticating peer, it will not have access to the user's
identity. Therefore, the DIAMETER Server SHOULD return the user's
identity by inserting it in the User-Name attribute of subsequent
DIAMETER-EAP-Response and DIAMETER-EAP-Ack packets. Without the user's
identity, accounting and billing becomes very difficult to manage.
In cases where a backup DIAMETER servers is available, were the
primary server to fail at any time during the EAP conversation, it
would be desirable for the NAS to be able to redirect the conversation
to an alternate DIAMETER server. However, for the backup server to be
able to pick up the conversation, it must be provided with the state
of the EAP conversation prior to the interruption.
This can be accomplished by having the DIAMETER-EAP-Request include
the series of EAP-Packet attributes representing the previous history
of the EAP conversation. Similarly, the DIAMETER-EAP-Response returned
by the DIAMETER server must also include all previous EAP-Packet
attributes. The sequence number field in the EAP-Packet attribute MUST
be used in order to determine which attribute is to be processed. The
attribute with the highest sequence number is the most recent
attribute.
The DIAMETER-EAP-Ack/EAP-Packet/EAP-Success packet MUST contain all of
the expected attributes which are currently returned in a DIAMETER
Authentication-Success packet.
For proxied DIAMETER requests there are two methods of processing. If
the domain is determined based on the DNIS the DIAMETER Server may
proxy the initial DIAMETER-EAP-Request/EAP-Start. If the domain is
determined based on the user's identity, the local DIAMETER Server
MUST respond with a DIAMETER-EAP-Response/EAP-Identity packet. The
response from the authenticating peer MUST be proxied to the final
Calhoun, Rubens, Aboba expires September 1998 [Page 5]
INTERNET DRAFT March 1998
authentication server.
For proxied DIAMETER requests, the NAS may receive an Command
Unrecongnized packet in response to its DIAMETER-EAP-Request/EAP-
Identity packet. This would occur if the message was proxied to a
DIAMETER Server which does not support the DIAMETER EAP extensions. At
this point, the NAS MUST re-open LCP with the authenticating peer and
request either CHAP or PAP as the authentication protocol.
If the NAS is unable to negotiate EAP with the authenticating peer,
what happens next is a matter of policy. In circumstances where EAP is
required of all users accessing the NAS, the NAS MUST disconnect the
user. However, in circumstances where EAP is mandatory for some users,
and optional or not required for others, the decision cannot be made
until the user's identity is ascertained. In this case, the NAS will
negotiate another authentication method, such as CHAP, and will pass
the User-Name and CHAP-Password attributes to the DIAMETER Server in
an Authentication-Request message. If the user is not required to use
EAP, then the DIAMETER Server will respond with an Authentication-
Success or Authentication-Failure packet as appropriate. However,
should the user require EAP, then the DIAMETER Server will respond
with an DIAMETER-EAP-Response packet containing an EAP-Packet
attribute. The EAP-Packet attribute will either encapsulate an EAP-
Request/Identity packet, or if the DIAMETER Server makes use of the
User-Name attribute in the Authentication-Request, it may encapsulate
an EAP challenge. On receiving the EAP-Packet attribute, the NAS will
either attempt to negotiate EAP if it had not done so previously, or
if negotiation had previously been attempted and failed, it MUST
disconnect the user.
The NAS is not responsible for the retransmission of any EAP messages.
The authenticating peer and the DIAMETER Server are responsible for
any retransmissions.
2.1 Example of an OTP Authentication
The example below shows the conversation between the authenticating
peer, NAS, and server, for the case of a One Time Password (OTP)
authentication. OTP is used only for illustrative purposes; other
authentication protocols could also have been used, although they
would show somewhat different behavior. For brevity, the history of
previous EAP messages (which will be transmitted in each DIAMETER-EAP-
Request and DIAMETER-EAP-Response packet) has been left out.
Authenticating Peer NAS DIAMETER Server
------------------- --- ---------------
<- PPP LCP Request-EAP
auth
Calhoun, Rubens, Aboba expires September 1998 [Page 6]
INTERNET DRAFT March 1998
PPP LCP ACK-EAP
auth ->
DIAMETER-
EAP-Request/
EAP-Packet/Start ->
<- DIAMETER-
EAP-Response/
EAP-Packet/Identity
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
DIAMETER-
EAP-Request/
EAP-Packet/
EAP-Response/
(MyID) ->
<- DIAMETER-
EAP-Response/
EAP-Packet/EAP-Request
OTP/OTP Challenge
<- PPP EAP-Request/
OTP/OTP Challenge
PPP EAP-Response/
OTP, OTPpw ->
DIAMETER-
EAP-Request/
EAP-Packet/
EAP-Response/
OTP, OTPpw ->
<- DIAMETER-EAP-Ack/
EAP-Packet/EAP-Success
(other attributes)
<- PPP EAP-Success
PPP Authentication
Phase complete,
NCP Phase starts
2.2 NAS Initiated EAP Authentication
In the case where the NAS sends the authenticating peer an EAP-
Request/Identity packet without first sending an EAP-Start packet to
the DIAMETER server, the conversation would appear as follows:
Authenticating Peer NAS DIAMETER Server
------------------- --- ---------------
<- PPP LCP Request-EAP
Calhoun, Rubens, Aboba expires September 1998 [Page 7]
INTERNET DRAFT March 1998
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
DIAMETER-
EAP-Request/
EAP-Packet/
EAP-Response/
(MyID) ->
<- DIAMETER-
EAP-Response/
EAP-Packet/EAP-Request
OTP/OTP Challenge
<- PPP EAP-Request/
OTP/OTP Challenge
PPP EAP-Response/
OTP, OTPpw ->
DIAMETER-
EAP-Request/
EAP-Packet/
EAP-Response/
OTP, OTPpw ->
<- DIAMETER-EAP-Ack/
EAP-Packet/EAP-Success
(other attributes)
<- PPP EAP-Success
PPP Authentication
Phase complete,
NCP Phase starts
2.3 Example of failed EAP Authentication
In the case where the client fails EAP authentication, the
conversation would appear as follows:
Authenticating Peer NAS DIAMETER Server
------------------- --- ---------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
DIAMETER-
EAP-Request/
EAP-Packet/Start ->
<- DIAMETER-
Calhoun, Rubens, Aboba expires September 1998 [Page 8]
INTERNET DRAFT March 1998
EAP-Response/
EAP-Packet/Identity
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
DIAMETER-
EAP-Request/
EAP-Packet/
EAP-Response/
(MyID) ->
<- DIAMETER-
EAP-Response/
EAP-Packet/EAP-Request
OTP/OTP Challenge
<- PPP EAP-Request/
OTP/OTP Challenge
PPP EAP-Response/
OTP, OTPpw ->
DIAMETER-
EAP-Request/
EAP-Packet/
EAP-Response/
OTP, OTPpw ->
<- DIAMETER-
EAP-Reject/
EAP-Packet/EAP-Failure
<- PPP EAP-Failure
<- LCP Terminate
2.4 Example of DIAMETER not supporting EAP
In the case that the DIAMETER server or proxy does not support EAP
extensions the conversation would appear as follows:
Authenticating Peer NAS DIAMETER Server
------------------- --- ---------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
DIAMETER
EAP-Request/
EAP-Packet/Start ->
<- DIAMETER
Command-Unrecognized
<- PPP LCP Request-CHAP
Calhoun, Rubens, Aboba expires September 1998 [Page 9]
INTERNET DRAFT March 1998
auth
PPP LCP ACK-CHAP
auth ->
<- PPP CHAP Challenge
PPP CHAP Response ->
DIAMETER
Authentication-Request->
<- DIAMETER
Authentication-Success
<- PPP LCP
CHAP-Success
PPP Authentication
Phase complete,
NCP Phase starts
2.5 Example of DIAMETER Proxy not supporting EAP
In the case where the local DIAMETER Server does support the EAP
extensions but the remote DIAMETER Server does not, the conversation
would appear as follows:
Authenticating Peer NAS DIAMETER Server
------------------- --- ---------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
DIAMETER-
EAP-Request/
EAP-Packet/Start ->
<- DIAMETER-
EAP-Response/
EAP-Packet/Identity
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity
(MyID) ->
DIAMETER-
EAP-Request/
EAP-Packet/EAP-Response/
(MyID) ->
<- DIAMETER-
EAP-Reject
(proxied from remote
DIAMETER Server)
<- PPP LCP Request-CHAP
Calhoun, Rubens, Aboba expires September 1998 [Page 10]
INTERNET DRAFT March 1998
auth
PPP LCP ACK-CHAP
auth ->
<- PPP CHAP Challenge
PPP CHAP Response ->
DIAMETER
Authentication-Request->
<- DIAMETER
Authentication-Success
(proxied from remote
DIAMETER Server)
<- PPP LCP
CHAP-Success
PPP Authentication
Phase complete,
NCP Phase starts
2.6 Example of PPP Client not supporting EAP
In the case where the authenticating peer does not support EAP, but
where EAP is required for that user, the conversation would appear as
follows:
Authenticating Peer NAS DIAMETER Server
------------------- --- ---------------
<- PPP LCP Request-EAP
auth
PPP LCP NAK-EAP
auth ->
<- PPP LCP Request-EAP
auth
PPP LCP NAK-EAP
auth ->
<- PPP LCP Request-CHAP
auth
PPP LCP ACK-CHAP
auth ->
<- PPP CHAP Challenge
PPP CHAP Response ->
DIAMETER-
Authentication-Request/
User-Name,
CHAP-Password ->
<- DIAMETER-
EAP-Response/
EAP-Packet
<- LCP Terminate Req
Calhoun, Rubens, Aboba expires September 1998 [Page 11]
INTERNET DRAFT March 1998
3.0 Alternative uses
Currently the conversation between the backend security server and the
DIAMETER server is proprietary because of lack of standardization. In
order to increase standardization and provide interoperability between
DIAMETER vendors and backend security vendors, it is recommended that
DIAMETER-encapsulated EAP be used for this conversation.
This has the advantage of allowing the DIAMETER server to support EAP
without the need for authentication-specific code within the DIAMETER
server. Authentication-specific code can then reside on a backend
security server instead.
In the case where DIAMETER-encapsulated EAP is used in a conversation
between a DIAMETER server and a backend security server, the Security
Server will typically return an DIAMETER-EAP-Ack/EAP-Packet/EAP-
Success message without inclusion of the expected attributes currently
returned in an Authentication-Success. This means that the DIAMETER
server MUST add these attributes prior to sending an DIAMETER-EAP-
Ack/EAP-Packet/EAP-Success message to the NAS.
4.0 Command Name and Command Code
Command Name: DIAMETER-EAP-Request
Command Code: 18
Command Name: DIAMETER-EAP-Response
Command Code: 19
Command Name: DIAMETER-EAP-Ack
Command Code: 20
Command Name: DIAMETER-EAP-Reject
Command Code: 21
5.0 Command Meanings
5.1 DIAMETER-EAP-Request
Description
DIAMETER-EAP-Request command is sent by the DIAMETER Client to the
DIAMETER Server, and convey EAP-Responses from the client through
the NAS and on to the DIAMETER server. DIAMETER-EAP-Requests will
normally include at least one EAP-Packet attribute which contains
the EAP packets. A DIAMETER-EAP-Request sent from the NAS to the
DIAMETER Server that does not contain an EAP-Packet attribute
signals to the DIAMETER Server that it is to initiate EAP
Calhoun, Rubens, Aboba expires September 1998 [Page 12]
INTERNET DRAFT March 1998
authentication with the client.
Upon receipt of a DIAMETER-EAP-Request, A DIAMETER Server MUST
issue a reply. The reply may be either: 1) a DIAMETER-EAP-Response
containing an EAP-Request in at lease one EAP-Packet attribute, 2)
a DIAMETER-EAP-Ack containing an EAP-Packet of type "success", or
3) a DIAMETER-EAP-Reject containing an EAP-Packet of type
"failure". A Command-Unrecognized packet is returned if the server
does not support the EAP extensions.
The DIAMETER-EAP-Request message MUST include either the Signature
or the Digital-Signature attribute depending upon the local policy.
A DIAMETER Server MUST calculate the correct calue of the Signature
and silently discard the packet if it does not match the value
sent.
A summary of the DIAMETER-EAP-Request packet 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Command Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type
256 DIAMETER Command
Length
The length of this attribute MUST be 9.
Flags
The flag field MUST have bit 1 (Mandatory Support) set.
Command Type
The Command Type field MUST be set to 18 (DIAMETER-EAP-Request).
5.2 DIAMETER-EAP-Response
Description
Calhoun, Rubens, Aboba expires September 1998 [Page 13]
INTERNET DRAFT March 1998
DIAMETER-EAP-Response packets are sent by the DIAMETER Server to
the NAS. They contain the next EAP-Request packet to be passed to
the client.
The DIAMETER-EAP-Response MUST contain at least one EAP-Packet
attribute and MUST include either the Signature or the Digital-
Signature attribute depending upon the local policy. A DIAMETER
Server MUST calculate the correct calue of the Signature and
silently discard the packet if it does not match the value sent.
After issuing the included EAP-Request to the client, the NAS
remains in a state where it awaits further EAP-Responses from the
client.
A summary of the DIAMETER-EAP-Response packet 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Command Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type
256 DIAMETER Command
Length
The length of this attribute MUST be 9.
Flags
The flag field MUST have bit 1 (Mandatory Support) set.
Command Type
The Command Type field MUST be set to 19 (DIAMETER-EAP-Response).
5.3 DIAMETER-EAP-Ack
Description
DIAMETER-EAP-Ack packets are sent by the DIAMETER Server to the
Calhoun, Rubens, Aboba expires September 1998 [Page 14]
INTERNET DRAFT March 1998
NAS. They contain the next EAP-Request or EAP-Success packet to be
passed to the client.
The DIAMETER-EAP-Ack packet MUST contain at least one EAP-Packet
attribute and MUST include either the Signature or the Digital-
Signature attribute depending upon the local policy. A DIAMETER
Server MUST calculate the correct calue of the Signature and
silently discard the packet if it does not match the value sent.
After issuing the included EAP-Success packet to the client, the
NAS should end the authentication phase with a positive response.
A summary of the DIAMETER-EAP-Ack packet 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Command Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type
256 DIAMETER Command
Length
The length of this attribute MUST be 9.
Flags
The flag field MUST have bit 1 (Mandatory Support) set.
Command Type
The Command Type field MUST be set to 20 (DIAMETER-EAP-Ack).
5.4 DIAMETER-EAP-Reject
Description
DIAMETER-EAP-Reject packets are sent by the DIAMETER Server to the
NAS. They are sent in response to a DIAMETER-EAP-Request that
results in an authentication failure. DIAMETER-EAP-Reject packets
Calhoun, Rubens, Aboba expires September 1998 [Page 15]
INTERNET DRAFT March 1998
contain at least one EAP-Packet attribute containing an EAP failure
packet.
After issuing the included EAP failure packet to the client, the
NAS should end the authentication phase with a negative result.
The DIAMETER-EAP-Reject message MUST include either the Signature
or the Digital-Signature attribute depending upon the local policy.
A DIAMETER Server MUST calculate the correct calue of the Signature
and silently discard the packet if it does not match the value
sent.
A summary of the DIAMETER-EAP-Reject packet 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Command Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type
256 DIAMETER Command
Length
The length of this attribute MUST be 9.
Flags
The flag field MUST have bit 1 (Mandatory Support) set.
Command Type
The Command Type field MUST be set to 21 (DIAMETER-EAP-Reject).
6.0 Attribute Name and Attribute Code
Attribute Name: EAP-Packet
Attribute Code: 277
7.0 Attribute Meanings
Calhoun, Rubens, Aboba expires September 1998 [Page 16]
INTERNET DRAFT March 1998
7.1 EAP-Packet
Description
This attribute is used to contain the actual EAP-Requests to be
sent from the DIAMETER server to the client (DIAMETER-EAP-Ack and
DIAMETER-EAP-Reject) and the EAP-Responses to be sent from the
client to the DIAMETER server (DIAMETER-EAP-Requests). These EAP-
Requests and Responses are exactly as defined in [1].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Sequence Number | String ... |
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
277 for EAP-Packet
Length
>= 7
Flags
The flag field MUST have bit 1 (Mandatory Support) set.
Sequence Number
The Sequence Number field is used in order to build a "history" of
the transaction. The EAP-Packet attribute with the highest Sequence
Number represents the current packet to process. The history is
passed along in each request/responses in order in order to support
the concept of DIAMETER backup servers, as described earlier.
String
The String field is the exact EAP packet data to be transported
from client to server or server to client. It is not Null
terminated and may contain arbitrary binary values.
Calhoun, Rubens, Aboba expires September 1998 [Page 17]
INTERNET DRAFT March 1998
8.0 Acknowledgments
Thanks to Dave Dawson and Karl Fox of Ascend, Glen Zorn and Narendra
Gidwani of Microsoft and Jeff Haag of 3Com for useful discussions of this
problem space.
9.0 References
[1] L. J. Blunk, J. R. Vollbrecht, "PPP Extensible Authentication
Protocol (EAP)." draft-ietf-pppext-eap-auth-02.txt, June, 1996.
[2] P. R. Calhoun, "DIAMETER Authentication Extension",
draft-calhoun-diameter-auth-00.txt, February 1998.
[3] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote
Authentication Dial In User Service (RADIUS)." RFC 2058,
January, 1997.
[4] C. Rigney, "RADIUS Accounting." RFC 2059, January 1997.
[5] R. Rivest, S. Dusse, "The MD5 Message-Digest Algorithm",
RFC 1321, April 1992
[6] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels." draft-bradner-key-words-02.txt, August 1996.
[7] P. R. Calhoun, A. Rubens, "DIAMETER Base Protocol",
draft-calhoun-diameter-00.txt, February 1998.
10.0 Authors' Addresses
Questions about this memo can be directed to:
Pat R. Calhoun
Technology Development
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, California, 94025
USA
Phone: 1-847-548-9587
Fax: 1-650-786-6445
E-mail: pcalhoun@toast.net
Allan C. Rubens
Merit Network, Inc.
4251 Plymouth Rd.
Calhoun, Rubens, Aboba expires September 1998 [Page 18]
INTERNET DRAFT March 1998
Ann Arbor, MI 48105-2785
Phone: 1-313-647-0417
E-Mail: acr@merit.edu
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 1-425-936-6605
E-Mail: bernarda@microsoft.com
Calhoun, Rubens, Aboba expires September 1998 [Page 19]