Internet Draft Pat R. Calhoun
Category: Experimental US Robotics Access Corp.
expires in six months Allan Rubens
Merit Network, Incorporated
Bernard Aboba
Microsoft
March 1997
DIAMETER
Extensible Authentication Protocol Support
<draft-calhoun-DIAMETER-eap-00.txt>
Status of this Memo
Distribution of this memo is unlimited.
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``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 (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
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 Protocl may be used in
conjunction with the DIAMETER protocol.
Calhoun, Rubens & Aboba [Page 1]
DRAFT Extensible Authentication Protocol Support March 1997
1. 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, new messages are being introduced in
this document.
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 new commands defined in this
document. 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.
2. Requirements language
This specification uses the same words as [6] for defining the
significance of each particular requirement. These words are:
MUST This word, or the adjectives "REQUIRED" or "SHALL", means
that the definition is an absolute requirement of the
specification.
MUST NOT This phrase, or the phrase "SHALL NOT", 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 a particular item, but the full implications must be
understood and carefully weighed before choosing a different
course.
SHOULD NOT
This phrase means that there may exist valid reasons in
particular circumstances when the particular behavior is
acceptable or even useful, but the full implications should
be understood and the case carefully weighed before
implementing any behavior described with this label.
Calhoun, Rubens & Aboba [Page 2]
DRAFT Extensible Authentication Protocol Support March 1997
MAY This word, or the adjective "OPTIONAL", means that an item
is truly optional. One vendor may choose to include the
item because a particular marketplace requires it or because
the vendor feels that it enhances the product while another
vendor may omit the same item. An implementation which does
not include a particular option MUST be prepared to
interoperate with another implementation which does include
the option, though perhaps with reduced functionality. In
the same vein an implementation which does include a
particular option MUST be prepared to interoperate with
another implementation which does not include the option.
(except, of course, for the feature the option provides)
An implementation is not compliant if it fails to satisfy one or more
of the must or must not requirements for the protocols it implements.
An implementation that satisfies all the must, must not, should and
should not requirements for its protocols is said to be
"unconditionally compliant"; one that satisfies all the must and must
not requirements but not all the should or should not requirements for
its protocols is said to be "conditionally compliant."
3. 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 Access-Request 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
Calhoun, Rubens & Aboba [Page 3]
DRAFT Extensible Authentication Protocol Support March 1997
phase. Note that if a 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 an
Access-Accept packet.
Calhoun, Rubens & Aboba [Page 4]
DRAFT Extensible Authentication Protocol Support March 1997
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
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 Access-Request packet. If the user is not required to use EAP,
then the DIAMETER Server will respond with an Access-Accept or
Access-Reject 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
Access-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.
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.
Calhoun, Rubens & Aboba [Page 5]
DRAFT Extensible Authentication Protocol Support March 1997
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-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
Calhoun, Rubens & Aboba [Page 6]
DRAFT Extensible Authentication Protocol Support March 1997
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
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
Calhoun, Rubens & Aboba [Page 7]
DRAFT Extensible Authentication Protocol Support March 1997
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 ->
Access-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-Reject/
EAP-Packet/EAP-Failure
<- PPP EAP-Failure
(client disconnected)
Calhoun, Rubens & Aboba [Page 8]
DRAFT Extensible Authentication Protocol Support March 1997
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
Access-Request/
EAP-Packet/Start ->
<- DIAMETER
Command-Unrecognized
<- PPP LCP Request-CHAP
auth
PPP LCP ACK-CHAP
auth ->
<- PPP CHAP Challenge
PPP CHAP Response ->
DIAMETER
Access-Request->
<- DIAMETER
Access-Accept
<- PPP LCP
CHAP-Success
PPP Authentication
Phase complete,
NCP Phase starts
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 ->
Calhoun, Rubens & Aboba [Page 9]
DRAFT Extensible Authentication Protocol Support March 1997
<- 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
auth
PPP LCP ACK-CHAP
auth ->
<- PPP CHAP Challenge
PPP CHAP Response ->
DIAMETER
Access-Request->
<- DIAMETER
Access-Accept
(proxied from remote
DIAMETER Server)
<- PPP LCP
CHAP-Success
PPP Authentication
Phase complete,
NCP Phase starts
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-CHAP
auth
Calhoun, Rubens & Aboba [Page 10]
DRAFT Extensible Authentication Protocol Support March 1997
PPP LCP ACK-CHAP
auth ->
<- PPP CHAP Challenge
PPP CHAP Response ->
DIAMETER-
Access-Request/
User-Name,
CHAP-Password ->
<- DIAMETER-
EAP-Response/
EAP-Packet
(User Disconnected)
5. 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 Access-Accept. 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.
2. Command Name and Command Code
Command Name: DIAMETER-EAP-Request
Command Code: 300
Command Name: DIAMETER-EAP-Response
Command Code: 301
Command Name: DIAMETER-EAP-Ack
Command Code: 302
Calhoun, Rubens & Aboba [Page 11]
DRAFT Extensible Authentication Protocol Support March 1997
Command Name: DIAMETER-EAP-Reject
Command Code: 303
3. Command Meanings
3.1 DIAMETER-EAP-Request
Description
DIAMETER-EAP-Request packets are 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
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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Flags | Ver | Command |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Integrity Code |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Calhoun, Rubens & Aboba [Page 12]
DRAFT Extensible Authentication Protocol Support March 1997
Code
254 for DIAMETER.
Flags
The Following bits MAY be used in the Access-Request:
0x1 - (Bit 12) TimeStamp is included in the Authenticator Field.
0x2 - (Bit 11) All attributes in packets are encrypted.
0x4 - (Bit 10) Authenticate-Only
0x8 - (Bit 9) Authorize-Only
See [7] for more information on the encryption algorithm used.
Version
MUST be set to 2
Command
300 for DIAMETER-EAP-Request
Identifier
The Identifier field MUST be changed whenever the content of the
Attributes field changes, and whenever a valid reply has been
received for a previous request. For retransmissions, the
Identifier MAY remain unchanged.
Length
The total length of the message, including this header.
Authenticator
The Authenticator field is a random 16 octet value. If the
Timestamp option is supported, the first four octets contain a
timestamp of when the packet was sent from the peer.
Message Integrity Code
This field contains an MD5 hash of the following:
MD5( packet | Shared Secret )
Calhoun, Rubens & Aboba [Page 13]
DRAFT Extensible Authentication Protocol Support March 1997
Attributes
The Attribute field is variable in length, and contains a list of
zero or more Attributes. It MAY contain one or more EAP-Packet
attributes. If it does not contain an EAP-Packet attribute, it is
an indication to the server that server that EAP should be
initiated by the server. See the description on EAP-Packet
attribute for more information on its use.
DIAMETER attributes which are normally found in an Access-Request MAY
be present in the request.
3.2 DIAMETER-EAP-Response
Description
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.
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-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Flags | Ver | Command |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Integrity Code |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Calhoun, Rubens & Aboba [Page 14]
DRAFT Extensible Authentication Protocol Support March 1997
Code
254 for DIAMETER.
Flags
The Following bits MAY be used in the Access-Request:
0x1 - (Bit 12) TimeStamp is included in the Authenticator Field.
0x2 - (Bit 11) All attributes in packets are encrypted.
0x4 - (Bit 10) User Authenticated Only
0x8 - (Bit 9) User Authorized Only
See [7] for more information on the encryption algorithm used.
Version
MUST be set to 2
Command
301 for DIAMETER-EAP-Response
Identifier
The Identifier field is a copy of the Identifier field of the
DIAMETER-EAP-Request which caused this DIAMETER-EAP-Ack to be sent.
Length
The total length of the message, including this header.
Authenticator
The Authenticator field is a random 16 octet value. If the
Timestamp option is supported, the first four octets contain a
timestamp of when the packet was sent from the peer.
Message Integrity Code
This field contains an MD5 hash of the following:
MD5( packet | Shared Secret )
Calhoun, Rubens & Aboba [Page 15]
DRAFT Extensible Authentication Protocol Support March 1997
Attributes
The Attribute field MUST contains at least one EAP-Packet attribute
which contains an EAP-Request packet.
3.3 DIAMETER-EAP-Ack
Description
DIAMETER-EAP-Ack packets are sent by the DIAMETER Server to the 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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Flags | Ver | Command |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Integrity Code |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
254 for DIAMETER.
Calhoun, Rubens & Aboba [Page 16]
DRAFT Extensible Authentication Protocol Support March 1997
Flags
The Following bits MAY be used in the Access-Request:
0x1 - (Bit 12) TimeStamp is included in the Authenticator Field.
0x2 - (Bit 11) All attributes in packets are encrypted.
0x4 - (Bit 10) User Authenticated Only
0x8 - (Bit 9) User Authorized Only
See [7] for more information on the encryption algorithm used.
Version
MUST be set to 2
Command
302 for DIAMETER-EAP-Ack
Identifier
The Identifier field is a copy of the Identifier field of the
DIAMETER-EAP-Request which caused this DIAMETER-EAP-Ack to be sent.
Length
The total length of the message, including this header.
Authenticator
The Authenticator field is a random 16 octet value. If the
Timestamp option is supported, the first four octets contain a
timestamp of when the packet was sent from the peer.
Message Integrity Code
This field contains an MD5 hash of the following:
MD5( packet | Shared Secret )
Attributes
The Attribute field contains only a single EAP-Packet attribute
which contains an EAP-Request packet.
Calhoun, Rubens & Aboba [Page 17]
DRAFT Extensible Authentication Protocol Support March 1997
3.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 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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Flags | Ver | Command |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Integrity Code |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
254 for DIAMETER.
Flags
The Flag field is used as defined in [7].
Version
MUST be set to 2
Calhoun, Rubens & Aboba [Page 18]
DRAFT Extensible Authentication Protocol Support March 1997
Command
303 for DIAMETER-EAP-Reject
Identifier
The Identifier field is a copy of the Identifier field of the
DIAMETER-EAP-Request which caused this DIAMETER-EAP-Reject to be sent.
Length
The total length of the message, including this header.
Authenticator
The Authenticator field is a random 16 octet value. If the
Timestamp option is supported, the first four octets contain a
timestamp of when the packet was sent from the peer.
Message Integrity Code
This field contains an MD5 hash of the following:
MD5( packet | Shared Secret )
Attributes
The Attribute field contains only a single EAP-Packet attribute
which contains an EAP-Request packet. Other attributes valid
on an Access-Reject message may also be present.
4. Attribute Name and Attribute Code
Attribute Name: EAP-Packet
Attribute Code: 300
5. Attribute Meanings
5.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].
Calhoun, Rubens & Aboba [Page 19]
DRAFT Extensible Authentication Protocol Support March 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Sequence Number | String ... | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
300 for EAP-Packet
Length
>= 6
Flags
The Flags field indicates how the NAS or DIAMETER Server MUST react
to the attribute. The following values are currently supported:
1 - The Device MUST support this attribute. If the attribute
is NOT supported, the device MUST reject the Command.
If this flag is not set, then the device MAY accept the
command regardless of whether or not the particular attribute
is recognized. This bit MUST be set.
2 - If this bit is set, the contents of the attributes are
encrypted. Note that the attribute header is NOT encrypted in
this case. See [7] for more information on the encryption
algorithm.
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 [Page 20]
DRAFT Extensible Authentication Protocol Support March 1997
7. Acknowledgments
Thanks to Dave Dawson and Karl Fox of Ascend, and Glen Zorn and
Narendra Gidwani of Microsoft for useful discussions of this problem
space.
8. References
[1] L. J. Blunk, J. R. Vollbrecht. "PPP Extensible Authentication
Protocol (EAP)." draft-ietf-pppext-eap-auth-02.txt, Merit Network,
Inc., June, 1996.
[2] P.R. Calhoun, A. Rubens, B. Aboba.
"Extensible Authentication Protocol Support in RADIUS"
US Robotics Access Corp., Merit Network, Inc., Microsoft Corp,
February, 1997.
[3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti-
cation Dial In User Service (RADIUS)." RFC 2058, Livingston, Merit,
Daydreamer, January, 1997.
[4] C. Rigney. "RADIUS Accounting." RFC 2059, Livingston, January,
1997.
[5] R. Rivest, S. Dusse. "The MD5 Message-Digest Algorithm", RFC
1321, MIT Laboratory for Computer Science, RSA Data Security Inc.,
[6] S. Bradner. "Key words for use in RFCs to Indicate Requirement
Levels." draft-bradner-key-words-02.txt, Harvard University, August,
1996.
[7] P.R. Calhoun, A. Rubens, "DIAMETER", Internet-Draft, March 1997.
Calhoun, Rubens & Aboba [Page 21]
DRAFT Extensible Authentication Protocol Support March 1997
9. Authors' Addresses
Pat R. Calhoun
US Robotics Access Corp.
8100 N. McCormick Blvd.
Skokie, IL 60076-2999
Phone: 847-342-6898
EMail: pcalhoun@usr.com
Allan C. Rubens
Merit Network, Inc.
4251 Plymouth Rd.
Ann Arbor, MI 48105-2785
Phone: 313-647-0417
EMail: acr@merit.edu
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 206-936-6605
EMail: bernarda@microsoft.com
Calhoun, Rubens & Aboba [Page 22]