Internet Draft
INTERNET DRAFT Pat R. Calhoun
Category: Standards Track Sun Microsystems, Inc.
Title: draft-calhoun-diameter-eap-03.txt Allan Rubens
Date: August 1999 Ascend Networks Inc.
Jeff Haag
Cisco Systems
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
::=
[]
{ ||
::=
Calhoun, Rubens, Haag expires January 2000 [Page 6]
INTERNET DRAFT August 1999
[]
{ ||
::=
[]
{ ||
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]