One document matched: draft-calhoun-diameter-eap-02.txt
Differences from draft-calhoun-diameter-eap-01.txt
INTERNET DRAFT Pat R. Calhoun
Category: Standards Track Sun Laboratories, Inc.
Title: draft-calhoun-diameter-eap-02.txt Allan Rubens
Date: November 1998 Merit Networks Inc.
Jeff Haag
Cisco Systems
DIAMETER Extensible Authentication Protocol Extensions
Status of this Memo
Comments should be submitted to the diameter@ipass.com mailing list.
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 view the entire list of current Internet-Drafts, please check
the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
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 DIAMETER Initiated EAP 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
2.6 Example of PPP Client not supporting EAP
3.0 Alternative uses
4.0 Command Codes
4.1 DIAMETER-EAP-Request
4.2 DIAMETER-EAP-Answer
5.0 DIAMETER AVPs
5.1 EAP-Packet
6.0 Acknowledgments
7.0 References
8.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 smart cards, Kerberos,
Public Key, One Time Passwords, and others. In order to provide for
support of EAP within DIAMETER, four new commands are introduced
in this document.
The scheme described here is similar to that proposed in [5], in that
the DIAMETER server is used to shuttle DIAMETER-encapsulated EAP
Packets between the NAS and a backend security server. However the
proposal described here does not suffer from the fragmentation and
lack of appropriate security mechanisms present in [5]. 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.
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 (dial-in user)
and the NAS begins with the negotiation of EAP within LCP. Once EAP has
been negotiated, the NAS MUST send an EAP-Request/Identity message to
the authenticating peer, unless identity is determined via some other
means such as Called-Station-Id or Calling-Stating-Id. The peer will then
respond with the EAP-Response/Identity which the NAS will then forward
to the DIAMETER server in the EAP-Packet AVP of the DIAMETER-EAP-Request
command. The DIAMETER server will typically use the EAP-Response/Identity
to determine which EAP type is to be applied to the user.
In order to simplify any DIAMETER Proxies task, the NAS MUST copy the
contents of the EAP-Response/Identity into the User-Name AVP and MUST
include the EAP-Response/Identity in the User-Name AVP in every
subsequent DIAMETER EAP messages. The DIAMETER Server MUST include the
User-Name in all DIAMETER-EAP-Answer packets as well. The Host-IP-Address
or Host-Name AVP SHOULD be present in all DIAMETER EAP messages. Without
the User-Name AVP, accounting and billing becomes very difficult to manage.
If identity is determined via another means such as Called-Station-Id
or Calling-Station-Id, the NAS MUST include these identifying
attributes in every DIAMETER-EAP-Request, and the DIAMETER Server MUST
include them in every DIAMETER-EAP-Answer message.
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 Called-Station-Id or Calling-Station-Id), and therefore an
EAP-Request/Identity packet may not necessarily be issued by the NAS
to the authenticating peer. In cases where an EAP-Request/Identity
packet will not be sent, the NAS will send to the DIAMETER server
a DIAMETER-EAP-Request packet containing an EAP-Packet attribute
signifying EAP-Start. EAP-Start is indicated by sending an EAP-Packet
attribute with a length of 2 (no data). However, it should be noted
that since no User-Name attribute is included in the
DIAMETER-EAP-Request, this approach cannot easily be applied in
situations where proxies are deployed, such as roaming or shared
use networks.
If the DIAMETER server supports EAP, it MUST respond with a
DIAMETER-EAP-Answer packet containing an EAP-Packet AVP. If the
DIAMETER server does not support EAP, it MUST respond with a
Message-Reject-Ind [2]. The EAP-Packet AVP includes an encapsulated EAP
packet which is then passed on to the authenticating peer. In the case
where the NAS does not initially send an EAP-Request/Identity message to
the peer, the DIAMETER-EAP-Answer typically will contain an EAP-Packet
AVP encapsulating an EAP-Request/Identity message, requesting the
dial-in user to identify themself. The NAS will then respond with a
DIAMETER-EAP-Request packet containing an EAP-Packet AVP encapsulating
an EAP-Response. The conversation continues until a DIAMETER-EAP-Answer
message is received with a Result-Code AVP indicating either success or
failure.
Reception of a DIAMETER-EAP-Answer packet with a Result-Code AVP that
indicates a failure, with or without an EAP-Packet AVP encapsulating
EAP-Failure, MUST result in the NAS issuing an LCP Terminate Request to
the authenticating peer. A DIAMETER-EAP-Answer packet with a Result-Code
AVP indicating success and an EAP-Packet AVP encapsulating EAP-Success
successfully ends the authentication phase. The
DIAMETER-EAP-Ack/EAP-Packet/EAP-Success packet MUST contain all of the
expected AVPs which are currently required for the requested service.
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.
For proxied DIAMETER requests there are two methods of processing. If
the domain is determined based on the Called-Station-Id, 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
Message-Reject-Ind 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
EAP extension. On receiving an Message-Reject-Ind, the NAS MUST send
an LCP Terminate Request to the authenticating peer, and disconnect.
It is expected that EAP will be used to implement a variety of
authentication methods, including methods involving strong cryptography.
In order to prevent attackers from subverting EAP by attacking
DIAMETER/EAP, (for example, by modifying the EAP-Success or
EAP-Failure packets) it is necessary that DIAMETER/EAP provide integrity
protection at least as strong as those used in the EAP methods
themselves.
The following provides examples of EAP authentication using OTP
under different conditions.
2.1 DIAMETER Initiated EAP 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.
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/
Result-Code OK/
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
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/
Result-Code OK/
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-
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/
Result-Code ! OK/
EAP-Packet/EAP-Failure
<- PPP EAP-Failure
<- PPP LCP Terminate
(User Disconnected)
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
Message-Reject-Ind
<- PPP LCP Terminate
(User Disconnected)
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-Answer/
EAP-Packet/Identity
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity
(MyID) ->
DIAMETER-
EAP-Request/
EAP-Packet/EAP-Response/
(MyID) ->
<- DIAMETER
Message-Reject-Ind
<- PPP LCP Terminate
(User Disconnected)
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-Answer/
EAP-Packet
<- LCP Terminate Req
(User Disconnected)
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-Answer/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-
Answer/EAP-Packet/EAP-Success message to the NAS.
4.0 Command Codes
This document defines the following DIAMETER Commands. All DIAMETER
implementations supporting this extension MUST support all of the
following commands:
Command Name Command Code
-----------------------------------
EAP-Packet TBD
DIAMETER-EAP-Request TBD
DIAMETER-EAP-Answer TDB
4.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.
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
"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.
The DIAMETER-EAP-Request message MUST include either the
Integrity- Check-Vector or the Digital-Signature AVP 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.
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 }
in 3 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|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
256 DIAMETER-Command
AVP Length
The length of this attribute MUST be at exactly 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'P' bits
MUST NOT be set.
Command Code
The Command Code field MUST be set to TBD (DIAMETER-EAP-
Request).
4.2 DIAMETER-EAP-Answer
Description
DIAMETER-EAP-Answer 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-Answer MUST contain at least one EAP-Packet AVP
and MUST include either the Integrity-Check-Vector or the
Digital-Signature AVP depending upon the local policy. A DIAMETER
Server MUST calculate the correct value of the authentication AVP
and silently discard the packet if it does not match the value
sent.
If the Result-Code AVP is present in the message it indicates that
authentication is complete, Otherwise after issuing the included
EAP-Request to the client, the NAS remains in a state where it
awaits further EAP-Responses from the client. This message with a
Result-Code AVP that indicates success MUST have an accompanying
EAP-Success message within the EAP-Packet AVP. If the Result-Code
AVP indicates failure, an accompanying EAP-Failure message SHOULD
be present in the EAP-Packet AVP.
A summary of the DIAMETER-EAP-Answer packet format is shown below.
The fields are transmitted from left to right.
Message Format
DIAMETER-EAP-Answer ::= <DIAMETER Header>
<DIAMETER-EAP-Answer Command AVP>
<Result-Code 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 }
in 3 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|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
256 DIAMETER-Command
AVP Length
The length of this attribute MUST be at exactly 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'P' bits
MUST NOT be set.
Command Code
The Command Code field MUST be set to TDB (DIAMETER-EAP-
Answer).
5.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
-----------------------------------
EAP-Packet TBD
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].
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|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
AVP Code
TBD EAP-Packet
AVP Length
The length of this attribute MUST be at least 24.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the
security model used. The 'V', 'T' and the 'P' bits MUST NOT be set.
Data
The String field is one or more octets, and should be unique to the
DIAMETER host. The Host Name MUST follow the NAI [6] naming conventions.
6.0 Acknowledgments
Thanks to Dave Dawson and Karl Fox of Ascend, Glen Zorn Jeff Haag
of 3Com for useful discussions.
7.0 References
[1] L. J. Blunk, J. R. Vollbrecht, "PPP Extensible Authentication
Protocol (EAP)." RFC 2284, March 1998.
[2] P. R. Calhoun, A. Rubens, "DIAMETER Base Protocol",
draft-calhoun-diameter-07.txt, Work in Progress,
November 1998.
[3] P. R. Calhoun, "DIAMETER Authentication Extension",
draft-calhoun-diameter-auth-04.txt,
Work in Progress, February 1998.
[4] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels." RFC 2119, August 1996.
[5] P. Calhoun, A. Rubens, B. Aboba, "Extensible Authentication
Protocol Support in RADIUS", draft-ietf-radius-eap-05.txt,
Work in Progress, May 1998.
[6] B. Aboba. "The Network Access Identifier."
draft-ietf-roamops-nai-11.txt, Work in Progress, July 1998.
8.0 Author's Address
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-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
W. Mark Townsley
Cisco Systems
7025 Kit Creek Road
PO Box 14987
Research Triangle Park, NC 27709
Phone: 1-919-472-2353
E-Mail: haag@cisco.com
| PAFTECH AB 2003-2026 | 2026-04-22 20:51:41 |