One document matched: draft-calhoun-diameter-eap-03.txt
Differences from draft-calhoun-diameter-eap-02.txt
DIAMETER
Extensible Authentication Protocol (EAP) Extensions
Status of this Memo
This document is an individual contribution for consideration by the
AAA Working Group of the Internet Engineering Task Force. Comments
should be submitted to the diameter@ipass.com mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
Abstract
The Extensible Authentication Protocol (EAP) is a PPP extension that
provides support for additional authentication methods within PPP.
This document describes how EAP can be carried within the DIAMETER
protocol to provide end to end authentication.
Calhoun, Rubens, Haag expires January 2000 [Page 1]
INTERNET DRAFT August 1999
Table of Contents
1.0 Introduction
1.1 Copyright Statement
1.2 Requirements language
1.3 Changes in version -02
2.0 Command Codes
2.1 DIAMETER-EAP-Request
2.2 DIAMETER-EAP-Answer
2.3 DIAMETER-EAP-Ind
3.0 DIAMETER AVPs
3.1 EAP-Packet
4.0 Protocol overview
4.1 Retransmission and Timers
4.2 Example of an OTP Authentication
4.2.1 Successful Authentication
4.2.2 NAS Initiated EAP Authentication
4.2.3 Server-Initiated Authentication
4.2.4 Example of failed EAP Authentication
4.2.5 Example of DIAMETER not supporting EAP
4.2.6 Example of DIAMETER Proxy not supporting EAP
4.2.7 Example of PPP Client not supporting EAP
4.3 Feature Advertisement/Discovery
5.0 Alternative uses
6.0 IANA Considerations
7.0 Acknowledgments
8.0 References
9.0 Authors' Addresses
10.0 Full Copyright Statement
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
Calhoun, Rubens, Haag expires January 2000 [Page 2]
INTERNET DRAFT August 1999
the backend security server vendor, it is also possible to use
DIAMETER-encapsulated EAP via the EAP-Packet AVP. 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 proposal serves three purposes:
1. It provides for end-to-end authentication, between the user and
his/her home DIAMETER server. End-to-End authentication, as
described in this specification, greatly reduces the possibility
for fraudulent authentication, such as replay attacks.
2. It allows for mutual (bi-directional) authentication. When PPP
or CHAP are used as the PPP authentication mechanism, it is not
possible to perform bi-directional authentication since the
authenticator (e.g. the NAS) does not have access to the DIAMETER
Server's authentication information. Although it would be
possible for the DIAMETER server to "download" the authentication
information to the NAS, even encrypted, it would be quite unwise
to do so in roaming environments where the NAS and the
authenticating DIAMETER server are not owned by the same
Administrative Domain.
3. It allows for home DIAMETER server initiated authentication.
Since the Home DIAMETER server may initially authenticate and
authorize the user for a finite period, it may periodically send
an authentication request to the user to ensure that the user is
still active. Furthermore, this will allow the Home DIAMETER
server to re-authorize the user for access for a finite amount of
time. See [8] for more information.
The Extension number for this draft is three (3). This value is
used in the Extension-Id Attribute value Pair (AVP) as defined in
[7].
1.1 Copyright Statement
Copyright (C) The Internet Society 1999. All Rights Reserved.
1.2 Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [6].
Calhoun, Rubens, Haag expires January 2000 [Page 3]
INTERNET DRAFT August 1999
1.3 Changes in version -03
The following changes were made in this revision of the document:
- The document introduces the DIAMETER-EAP-Ind to allow the server
to initiate an unsolicited authentication session with the PPP
client as described in [8].
- The AVP Header formats have changed since the last version of
this draft.
- IANA considerations were added, as well as many new useful
references.
- Well, to be honest, the list of changes are just too great list.
This document needed a good re-write. Here it is.
2.0 Command Codes
This section will define the Commands [1] for DIAMETER
implementations supporting the Mobile IP extension.
Command Name Command Code
-----------------------------------
DIAMETER-EAP-Request ???
DIAMETER-EAP-Answer ???
DIAMETER-EAP-Ind ???
2.1 DIAMETER-EAP-Request
Description
The DIAMETER-EAP-Request command is sent by a DIAMETER Client to a
DIAMETER Server and conveys an EAP-Response [1] from the dial-up
PPP Client. The DIAMETER-EAP-Request MUST contain one EAP-Packet
AVP, which contains the actual EAP payload. A EAP-Packet AVP with
no data MAY be sent to the DIAMETER Server to initiate an EAP
authentication session.
Upon receipt of a DIAMETER-EAP-Request, A DIAMETER Server MUST
issue a reply. The reply may be either:
1) a DIAMETER-EAP-Answer containing an EAP-Request in at lease
one EAP-Packet attribute
2) a DIAMETER-EAP-Answer containing an EAP-Packet of type
Calhoun, Rubens, Haag expires January 2000 [Page 4]
INTERNET DRAFT August 1999
"success" and a Result Code AVP indicating success
3) a DIAMETER-EAP-Answer containing an EAP-Packet of type
"failure" and a Result-Code AVP indicating failure.
4) A Message-Reject-Ind packet is returned if the server does
not support the EAP extensions.
Message Format
<DIAMETER-EAP-Request> ::= <DIAMETER Header>
<DIAMETER-EAP-Request Command AVP>
<Host-IP-Address AVP>
[<Host-Name AVP>]
<EAP-Packet AVP>
<User-Name AVP>
<Timestamp AVP>
<Initialization-Vector AVP>
{<Integrity-Check-Vector AVP> ||
<Digital-Signature AVP }
AVP Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length |CFlags |C|Z|Reservd|P|E|T|V|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
256 DIAMETER Command
AVP Length
The length of this attribute MUST be 12.
Command Flags
The following Command-specific flag bits may be set in the
DIAMETER-EAP-Request command:
Calhoun, Rubens, Haag expires January 2000 [Page 5]
INTERNET DRAFT August 1999
The 'C' (Authentication-only) bit may be set to indicate
that only authentication of the user is required, and that
no authorization should be performed. Additionally, no
authorization AVPs are expected in the DIAMETER-EAP-Answer
command.
AVP Flags
The 'M' bit MUST be set. The 'P' bits MAY be set if end to end
message integrity is required. The 'E', 'V', 'H' and 'T' bits
MUST NOT be set.
Command Code
The Command Code field MUST be set to ??? (DIAMETER-EAP-
Request).
2.2 DIAMETER-EAP-Answer
Description
The DIAMETER-EAP-Answer packets are sent by the DIAMETER Server to
the client in response to a DIAMETER-EAP-Request, and they contain
the next EAP-Request packet to be transmitted to the PPP client.
The DIAMETER-EAP-Answer message MUST include an EAP payload of
type EAP-Request [1] encapsulated within an EAP-Packet AVP.
If the Result-Code AVP is present in the message, it indicates
that the authentication is complete. Otherwise, after transmitting
the contents of the EAP-Packet AVP to the PPP client, the NAS
remains in a state where it awaits an EAP-Response [1] from the
PPP client. When the Result-Code AVP indicates success, it MUST
have an accompanying EAP-Success [1] message encapsulated within
the EAP-Packet AVP. If the Result-Code AVP indicates failure, an
accompanying EAP-Failure [1] message SHOULD be present in the EAP-
Packet AVP.
A DIAMETER-EAP-Answer with a successful Result-Code AVP and the
'C' bit NOT set MUST include the normal authorization AVPs that
one would find in an AA-Answer, as defined in [2].
Message Format
<DIAMETER-EAP-Answer> ::= <DIAMETER Header>
<DIAMETER-EAP-Answer Command AVP>
<Result-Code AVP>
<Host-IP-Address AVP>
Calhoun, Rubens, Haag expires January 2000 [Page 6]
INTERNET DRAFT August 1999
[<Host-Name AVP>]
<EAP-Packet AVP>
<User-Name AVP>
<misc. AVPs [2]>
<Timestamp AVP>
<Initialization-Vector AVP>
{<Integrity-Check-Vector AVP> ||
<Digital-Signature AVP }
AVP Format
A summary of the DIAMETER-EAP-Answer 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length |CFlags |C|Z|Reservd|P|E|T|V|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
256 DIAMETER Command
AVP Length
The length of this attribute MUST be 12.
Command Flags
The Command Specific flags MUST be set to the same value that
was found in the DIAMETER-EAP-Request. The following values are
supported:
The 'C' (Authentication-only) bit may be set to indicate
that only authentication of the user is required, and that
no authorization should be performed. Additionally, no
authorization AVPs are expected in the DIAMETER-EAP-Answer
command.
AVP Flags
The 'M' bit MUST be set. The 'P' bits MAY be set if end to end
message integrity is required. The 'E', 'V', 'H' and 'T' bits
Calhoun, Rubens, Haag expires January 2000 [Page 7]
INTERNET DRAFT August 1999
MUST NOT be set.
Command Code
The Command Code field MUST be set to ??? (DIAMETER-EAP-
Answer).
2.3 DIAMETER-EAP-Ind
Description
The DIAMETER-EAP-Ind command is sent as an unsolicited message
from the DIAMETER Server to a client, and is used to request a re-
authentication of the PPP client. The message MUST contain an EAP-
Packet AVP, which MAY contain either an identity request, or a
challenge request. It is recommended that the Identity Request be
bypassed since the user's identity is already known, and by
issuing the challenge directly, the number of round trips required
for re-authentication is greatly diminished.
Upon receipt of the message, the NAS MUST issue the EAP payload to
the PPP Client, and SHOULD respond with a DIAMETER-EAP-Request
containing the EAP-Response [1] packet.
Message Format
<DIAMETER-EAP-Ind> ::= <DIAMETER Header>
<DIAMETER-EAP-Ind Command AVP>
<Host-IP-Address AVP>
[<Host-Name AVP>]
<EAP-Packet AVP>
<User-Name AVP>
<Timestamp AVP>
<Initialization-Vector AVP>
{<Integrity-Check-Vector AVP> ||
<Digital-Signature AVP }
AVP Format
A summary of the DIAMETER-EAP-Ind packet format is shown below.
The fields are transmitted from left to right.
Calhoun, Rubens, Haag expires January 2000 [Page 8]
INTERNET DRAFT August 1999
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length |CFlags |C|Z|Reservd|P|E|T|V|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
256 DIAMETER Command
AVP Length
The length of this attribute MUST be 12.
Command Flags
The following Command-specific flag bits may be set in the
DIAMETER-EAP-Request command:
The 'C' (Authentication-only) bit may be set to indicate
that only authentication of the user is required, and that
no authorization should be performed. Additionally, no
authorization AVPs are expected in the DIAMETER-EAP-Answer
command.
AVP Flags
The 'M' bit MUST be set. The 'P' bits MAY be set if end to end
message integrity is required. The 'E', 'V', 'H' and 'T' bits
MUST NOT be set.
Command Code
The Command Code field MUST be set to ??? (DIAMETER-EAP-Ind).
3.0 DIAMETER AVPs
This section will define the mandatory AVPs which MUST be supported
by all DIAMETER implementations supporting this extension. The
following AVPs are defined in this document:
Attribute Name Attribute Code
-----------------------------------
Calhoun, Rubens, Haag expires January 2000 [Page 9]
INTERNET DRAFT August 1999
EAP-Packet ???
3.1 EAP-Packet
Description
This attribute is used to contain the actual EAP payload [1] to be
that is being exchanged between the dial-up PPP client and the
home authentication server.
AVP Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|E|T|V|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
AVP Code
??? EAP-Packet
AVP Length
The length of this attribute MUST be at least 8.
AVP Flags
The 'M' bit MUST be set. The 'P' bit MAY be set if end to end
message integrity is required. The 'H' or 'E' may be set if
the AVP is to be encrypted. The 'V', 'H' and 'T' bits MUST NOT
be set.
Data
The Data field contains an EAP Packet as defined in [1].
4.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
Calhoun, Rubens, Haag expires January 2000 [Page 10]
INTERNET DRAFT August 1999
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 8 (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-Answer packet containing an EAP-Packet AVP. The EAP-
Packet AVP includes an encapsulated EAP payload [1] which is then
passed on to the authenticating PPP client. The DIAMETER-EAP-Answer
typically will contain an EAP-Packet AVP encapsulating an EAP-
Request/Identity message, requesting the authenticating PPP client to
identify itself. The NAS will then respond with a DIAMETER-EAP-
Request packet containing an EAP-Packet AVP encapsulating an EAP-
Response [1], etc. The conversation continues until the DIAMETER
server sends a DIAMETER-EAP-Answer with a Result-Code AVP is
received. If the Result-Code AVP indicates an error, the EAP-Packet
AVP SHOULD encapsulate an EAP-Failure [1] and the NAS SHOULD
disconnect the user by issuing an LCP Terminate Request. If the
Result-Code AVO indicates success, the EAP-Packet AVP MUST
encapsulate an EAP-Success [1] and the NAS MUST successfully
terminate the PPP authentication phase.
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-Answer packets. Without the user's identity, accounting
and billing becomes very difficult to manage.
This document also describes the DIAMETER-EAP-Ind, which may be sent
by DIAMETER Servers in order to initiate an unsolicited EAP
authentication with the dial-up EAP Client. The document [8]
Calhoun, Rubens, Haag expires January 2000 [Page 11]
INTERNET DRAFT August 1999
describes a situation where this is advantageous. By allowing the
server to initiate the request, and to simply send an EAP challenge
(assuming that the actual authentication protocol does have the
concept of a challenge) the number of round trips required is
significantly diminished. Upon receipt of such a message, the
DIAMETER client is expected to send a DIAMETER-EAP-Request containing
an EAP-Response [1] payload.
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. In the event that this
should occur, the EAP transaction will have to start from the
beginning.
The DIAMETER-EAP-Answer with a successful Result-Code AVP MUST
contain an encapsulated EAP-Success [1]. If the Authenticate-Only bit
is NOT set, the packet MUST contain all of the expected AVPs that are
currently returned in a DIAMETER AA-Answer [2].
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-Answer/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
Unrecognized 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. See
section 4.2 for additional packet exchange information.
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
AA-Answer [2]. However, should the user require EAP, then the
DIAMETER Server will respond with an DIAMETER-EAP-Answer packet
Calhoun, Rubens, Haag expires January 2000 [Page 12]
INTERNET DRAFT August 1999
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 AA-
Request [2], 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.
4.1 Retransmission and Timers
As noted in [1], the EAP authenticator (NAS) is responsible for
retransmission of packets between the authenticating peer and the
NAS. Thus if an EAP packet is lost in transit between the
authenticating peer and the NAS (or vice versa), the NAS will
retransmit. As in DIAMETER [2], the DIAMETER client is responsible
for retransmission of packets between the DIAMETER client and the
DIAMETER server.
Note that it may be necessary to adjust authentication timeouts in
certain cases. For example, when a token card is used additional time
may be required to allow the user to find the card and enter the
token. Since the NAS will typically not haveknowledge of the required
parameters, these need to be provided by the DIAMETER server. This
can be accomplished by inclusion of EAP-Timeout and Password-Retry
attributes within the EAP-Response packet.
4.2 Example of an OTP Authentication
This section provides sample messages exchanges between an
Authenticating Peer, which is typically a dial-up PPP client, a NAS
and a DIAMETER server. The protocol used between the Dial-up PPP
client and the NAS is EAP over PPP as defined in [1]. The protocol
between the NAS and the DIAMETER Server is EAP encapsulated within
DIAMETER, as described in this specification.
For all PPP packets, the messages are formatted as:
[LCP Packet Type]
[EAP Packet Type]/[EAP Payload]
For all DIAMETER packets, the messages are formatted as:
[DIAMETER Command Code]/[EAP Packet Type]/[EAP Payload]
In the example provided below, the PPP client attempts to
authenticate using a One-Time-Password [12] encapsulated within EAP
[1].
Calhoun, Rubens, Haag expires January 2000 [Page 13]
INTERNET DRAFT August 1999
4.2.1 Successful 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.
Calhoun, Rubens, Haag expires January 2000 [Page 14]
INTERNET DRAFT August 1999
Authenticating Peer NAS DIAMETER Server
------------------- --- ---------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
DIAMETER-
EAP-Request/
EAP-Packet/Start ->
<- DIAMETER-
EAP-Answer/
EAP-Packet/Identity
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
DIAMETER-
EAP-Request/
EAP-Packet/
EAP-Response/
(MyID) ->
<- DIAMETER-
EAP-Answer/
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-Answer/
EAP-Packet/EAP-Success
(other attributes)
<- PPP EAP-Success
PPP Authentication
Phase complete,
NCP Phase starts
4.2.2 NAS Initiated EAP Authentication
In the case where the NAS sends the authenticating peer an
Calhoun, Rubens, Haag expires January 2000 [Page 15]
INTERNET DRAFT August 1999
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-Answer/
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-Answer/
EAP-Packet/EAP-Success
(other attributes)
<- PPP EAP-Success
PPP Authentication
Phase complete,
NCP Phase starts
4.2.3 Server-Initiated Authentication
As described in [8], when a server has successfully authenticated and
authorized a user, it may include a timeout period to the
Calhoun, Rubens, Haag expires January 2000 [Page 16]
INTERNET DRAFT August 1999
authorization. The server can later initiate an unsolicited re-
authentication request to the user, through the NAS. This method has
the advantage of reducing the number of round trips required for re-
authentication/authorization.
Authenticating Peer NAS DIAMETER Server
------------------- --- ---------------
<- DIAMETER-EAP-Ind/
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-Answer/
EAP-Packet/EAP-Success
(other attributes)
<- PPP EAP-Success
4.2.4 Example of failed EAP Authentication
In the case where the client fails EAP authentication,
the conversation would appear as follows:
Calhoun, Rubens, Haag expires January 2000 [Page 17]
INTERNET DRAFT August 1999
Authenticating Peer NAS DIAMETER Server
------------------- --- ---------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
DIAMETER-
EAP-Request/
EAP-Packet/Start ->
<- DIAMETER-
EAP-Answer/
EAP-Packet/Identity
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
DIAMETER-
EAP-Request/
EAP-Packet/
EAP-Response/
(MyID) ->
<- DIAMETER-
EAP-Answer/
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-Answer/
EAP-Packet/EAP-Failure
<- PPP EAP-Failure
<- LCP Terminate
4.2.5 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:
Calhoun, Rubens, Haag expires January 2000 [Page 18]
INTERNET DRAFT August 1999
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
auth
PPP LCP ACK-CHAP
auth ->
<- PPP CHAP Challenge
PPP CHAP Response ->
DIAMETER
AA-Request->
<- DIAMETER
AA-Answer
<- PPP LCP
CHAP-Success
PPP Authentication
Phase complete,
NCP Phase starts
4.2.6 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:
Calhoun, Rubens, Haag expires January 2000 [Page 19]
INTERNET DRAFT August 1999
Authenticating Peer NAS DIAMETER Server
------------------- --- ---------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
DIAMETER-
EAP-Request/
EAP-Packet/Start ->
<- DIAMETER-
EAP-Answer/
EAP-Packet/Identity
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity
(MyID) ->
DIAMETER-
EAP-Request/
EAP-Packet/EAP-Response/
(MyID) ->
<- DIAMETER-
EAP-Answer
(proxied from remote
DIAMETER Server)
<- PPP LCP Request-CHAP
auth
PPP LCP ACK-CHAP
auth ->
<- PPP CHAP Challenge
PPP CHAP Response ->
DIAMETER
AA-Request->
<- DIAMETER
AA-Answer
(proxied from remote
DIAMETER Server)
<- PPP LCP
CHAP-Success
PPP Authentication
Phase complete,
NCP Phase starts
4.2.7 Example of PPP Client not supporting EAP
In the case where the authenticating peer does not support EAP, but
Calhoun, Rubens, Haag expires January 2000 [Page 20]
INTERNET DRAFT August 1999
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-
AA-Request/
User-Name,
CHAP-Password ->
<- DIAMETER-
EAP-Answer/
EAP-Packet
<- LCP Terminate Req
4.3 Feature Advertisement/Discovery
As defined in [8], the Reboot-Ind and Device-Feature-Query messages
can be used to inform a peer about locally supported DIAMETER
Extensions. In order to advertise support of this extension, the
Extension-Id AVP must be transmitted with a value of three (3).
5.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.
Calhoun, Rubens, Haag expires January 2000 [Page 21]
INTERNET DRAFT August 1999
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-Aanswer/EAP-Packet/EAP-
Success message without inclusion of the expected attributes
currently returned in a successful AA-Answer [2]. This means that the
DIAMETER server MUST add these attributes prior to sending an
DIAMETER-EAP- Answer/EAP-Packet/EAP-Success message to the NAS.
6.0 IANA Considerations
The numbers for the Command Code AVPs (section 3) is taken from the
numbering space defined for Command Codes in [2]. The numbers for the
various AVPs defined in section 4 were taken from the AVP numbering
space defined in [2]. The numbering for the AVP and Command Codes
MUST NOT conflict with values specified in [2] and other DIAMETER
related Internet Drafts.
This document also introduces two new bits to the AVP Header, which
MUST NOT conflict with the base protocol [2] and any other DIAMETER
extension.
7.0 Acknowledgments
Thanks for Bernard Aboba for his contribution to [9]. Much of the
text found in this draft was taken directly from the said draft.
8.0 References
[1] L. J. Blunk, J. R. Vollbrecht, "PPP Extensible Authentication
Protocol (EAP)." RFC 2284, March 1998.
[2] P. R. Calhoun, "DIAMETER Authentication Extension",
draft-calhoun-diameter-auth-06.txt, August 1999.
[3] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote
Authentication Dial In User Service (RADIUS)." RFC 2138,
April 1997.
[4] C. Rigney, "RADIUS Accounting." RFC 2139, April 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", BCP 14, RFC 2119, March 1997.
Calhoun, Rubens, Haag expires January 2000 [Page 22]
INTERNET DRAFT August 1999
[7] P. R. Calhoun, A. Rubens, "DIAMETER Base Protocol",
draft-calhoun-diameter-08.txt, August 1999.
[8] G. Zorn, P. R. Calhoun, "Limiting Fraud in Roaming",
draft-ietf-roamops-fraud-limit-00.txt, May 1999.
[9] P. R. Calhoun, A. Rubens, B. Aboba, "Extensible Authentication
Protocol Support in RADIUS", draft-ietf-radius-eap-05.txt,
Work in Progress, May 1998.
[10] Narten, Alvestrand,"Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998
[11] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661,
July 1994.
[12] N Haller, C. Metz, P. Nesset, M. Straw, "A One-Time
Password (OTP) System", RFC 2289, February 1998.
[13] P. Calhoun, W. Bulley, "DIAMETER Proxy Server Extensions",
draft-calhoun-diameter-proxy-02.txt, Work in Progress,
August 1999.
9.0 Authors' Addresses
Questions about this memo can be directed to:
Pat R. Calhoun
Network and Security Research Center, Sun Labs
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, California, 94025
USA
Phone: 1-650-786-7733
Fax: 1-650-786-6445
E-mail: pcalhoun@eng.sun.com
Allan C. Rubens
Ascend Communications
1678 Broadway
Ann Arbor, MI 48105-1812
USA
Phone: 1-734-761-6025
E-Mail: acr@del.com
Jeff Haag
Cisco Systems
7025 Kit Creek Road
Calhoun, Rubens, Haag expires January 2000 [Page 23]
INTERNET DRAFT August 1999
PO Box 14987
Research Triangle Park, NC 27709
Phone: 1-919-392-2353
E-Mail: haag@cisco.com
10.0 Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implmentation may be prepared, copied,
published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this docu- ment itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Inter- net organizations, except as needed
for the purpose of developing Internet standards in which case
the procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English. The limited permis- sions granted
above are perpetual and will not be revoked by the Internet
Society or its successors or assigns. This document and the
information contained herein is provided on an "AS IS" basis and
THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WAR- RANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Calhoun, Rubens, Haag expires January 2000 [Page 24]
| PAFTECH AB 2003-2026 | 2026-04-22 13:59:40 |