Network Working Group Bernard Aboba
INTERNET-DRAFT Microsoft
<draft-aboba-ppp-01.txt>
19 November 1997
Lightweight Directory Access Protocol (v3):
Extension for PPP Authentication
1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work-
ing 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 mate-
rial 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).
The distribution of this memo is unlimited. It is filed as <draft-
aboba-ppp-01.txt>, and expires May 1, 1998. Please send comments to
the authors.
2. Abstract
This document defines the ''PPP Authentication Operation'' for LDAP.
This operation provides for PPP authentication in an LDAP association
and is defined in terms of an LDAP extended operation.
It is expected that this extended operation will be useful in inte-
grating authentication protocols such as RADIUS and TACACS+ with LDAP-
based directory services. Consolidation of information stores is
desirable since it results in lessened administrative workload and a
consistent view of user information throughout the enterprise.
3. Introduction
Currently RADIUS (described in [6]-[8]) and TACACS+ (described in
[12]) authentication servers typically include their own stores of
user data. In order to simplify user administration, it is desirable
to be able to integrate these services with an LDAP-based directory
service.
Aboba [Page 1]
INTERNET-DRAFT 19 November 1997
This document is one of three related specifications which describe
how a RADIUS server may be integrated with an LDAP-based directory
service. Reference [16] specifies how user data utilized by a RADIUS
server may be stored in an LDAP-based directory service. Reference
[17] describes a schema designed for tracking sessions in progress.
Such information can be useful for a variety of purposes including
security incident response; simultaneous usage control; or monitoring
of connection quality, login time, packet size or bandwidth usage. Due
to the frequency of changes to this data, dynamic attributes must be
employed, as described in [5].
PPP authentication protocols are described in [11],[14] and [15].
This document describes an LDAP extension supporting validation of
user credentials submitted during PPP authentication. This makes it
possible for the RADIUS server to validate user credentials received
in the Access-Request packet.
3.1. Alternatives for integration of PPP authentication methods
In order for a RADIUS server to be able to respond to an Access-
Request, a means must be available for validating user credentials.
However, current LDAP security mechanisms do not support PPP authenti-
cation methods so that extensions or protocol modifications are
required.
Several alternatives present themselves. One alternative is to add
support for PPP authentication methods to SASL, and utilize the secure
BIND mechanisms described in [18]. In this alternative, the RADIUS
server will impersonate the user and bind using the credentials sub-
mitted in the Access-Request. In this scenario, only the user would
need to have the access rights to retrieve RADIUS attributes from the
directory. There would not be a need to make these attributes accessi-
ble to a privileged account used by the RADIUS server, or to any net-
work devices. This is desirable from a security point of view.
Using this alternative, support for PPP authentication methods would
be added to SASL. The RADIUS server would set up an SSL/TLS connection
on startup, and would execute a BIND operation for each authentica-
tion; the server would only UNBIND on shutdown. This avoids the over-
head of an UNBIND and SSL/TLS connection setup for each authentica-
tion.
However, it should be noted that merely adding CHAP support to SASL
will not solve the problem posed here. This is because an LDAP-server
utilizing a CHAP extension to SASL would generate its own challenge,
rather than accepting a CHAP challenge and response submitted to it by
the RADIUS server. While such an approach would be compatible with
EAP-MD5, where the RADIUS server generates its own challenge, it would
not be compatible with CHAP, where the NAS generates the challenge and
passes both the CHAP challenge and the response to the RADIUS server
for evaluation.
Aboba [Page 2]
INTERNET-DRAFT 19 November 1997
Thus to solve the problem, it must be possible to submit both the CHAP
challenge and response to SASL. However, making it possible to authen-
ticate to an LDAP server using such a mechanism is not desirable since
it would make LDAP authentication susceptible to a replay attack.
Another alternative is to provide support for PPP authentication
within an LDAP extended operation. In this alternative, the RADIUS
server binds to the directory on startup using a special account, and
unbinds on shutdown. In between the bind and unbind, the RADIUS server
may submit as many PPP authentication requests as necessary. In this
scenario, the account used by the RADIUS server needs to have the
access rights to retrieve RADIUS attributes for any user.
Since the LDAP extension only returns a yes or no, but does not gain
the requester any privileges, it does not have the security problem
inherent in the SASL-based scheme described above. It is also believed
that this approach will utilize fewer resources on most implementa-
tions, since the continual execution of BIND operations, without cor-
responding UNBINDs, is likely to result in steady memory consumption
on the RADIUS server.
3.2. Overview
PPP Authentication is an extended operation initiated by an LDAP
client (RADIUS server) in order to request authentication of a user by
the LDAP-based directory. The LDAP client sends a PPP Authentication
request to the LDAP server, indicating the PPP authentication method,
and including the user's credentials, and the server then responds
with a message indicating the success or failure of the authentica-
tion.
When the RADIUS server receives an Access-Request packet from a NAS or
VPN server, it examines the User-Name attribute to determine the user
that is being authenticated. Based on the User-Name, the server may
also retrieve the authenticationType attribute for the user, and will
then check the authentication method specified in the Access-Request
against the permitted types. If there is a mis-match, then the server
will formulate and send an Access-Reject packet.
If the authentication indicated in the Access-Request is one of the
permitted types, and PAP or CHAP authentication is being used, the
RADIUS server utilizes the LDAP extension for PPP authentication spec-
ified in this document in order to verify the user's identity. Alter-
natively, the PPP authentication operation may be carried out syn-
chronously with retrieval of the RADIUS attributes described in [16],
and an Access-Reject can be sent if an authentication type mismatch is
detected after the retrieval (and possibly the PPP authentication
operation) is complete.
If the user authentication is unsuccessful, then the RADIUS server
will formulate and send an Access-Reject packet. If the user is suc-
cessfully authenticated, then the RADIUS server will formulate an
Access-Accept based on the attributes retreived from the LDAP-based
Aboba [Page 3]
INTERNET-DRAFT 19 November 1997
directory service, specified in [16].
If the Access-Request contains an EAP-Message attribute with a speci-
fied identity, then the RADIUS server will retrieve the user's RADIUS-
related information from the LDAP-based directory service in order to
determine the type of EAP authentication for this user. Depending on
the eapType, the RADIUS server will then either handle the authentica-
tion internally (such as for MD5), or may forward the request to a
security server. As a result, the PPP authentication operation
described in this document does not need to support EAP.
4. Protocol Additions
4.1. The Start PPP Authentication Operation
A client may perform a PPP authentication operation by transmitting an
LDAP PDU containing an ExtendedRequest. An LDAP ExtendedREquest is
defined as follows:
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING }
The requestName field must be set to the string "<OID-to-be-
assigned>".
This request is permitted to be invoked when LDAP is carried by a con-
nectionless transport.
When using a connection-oriented transport, there is no requirement
that this operation be on the same particular connection as any other.
A client may open multiple connections, or close and then reopen a
connection.
4.1.1. CHAP Authentication
When Challenge-Handshake Authentication Protocol (CHAP) authentication
is desired, the requestValue field will contain as a value the DER-
encoding of the following ASN.1 data type:
SEQUENCE {
authenticationProtocol [0] INTEGER,
algorithm [1] INTEGER,
name [2] OCTET STRING,
challenge [3] OCTET STRING,
chapIdent [4] OCTET STRING,
response [5] OCTET STRING
}
The authenticationProtocol field is an integer containing the Authen-
tication-Protocol number for CHAP, c223 (hex). The algorithm is an
Aboba [Page 4]
INTERNET-DRAFT 19 November 1997
integer indicating the one-way hash method to be used. Values include
MD5 (5). The name is an octet string identifying the user to be
authenticated. The challenge is a 16 octet string containing the CHAP
challenge sent by the NAS to a PPP CHAP user. The chapIdent is a sin-
gle octet containing the CHAP Identifer from the user's CHAP Response.
The response is a 16 octet field containing the CHAP Response from the
user.
4.1.2. PAP Authentication
When Password Authentication Protocol (PAP) authentication is desired,
the requestValue field will contain as a value the DER-encoding of the
following ASN.1 data type:
SEQUENCE {
authenticationProtocol [0] INTEGER,
name [1] OCTET STRING,
password [2] OCTET STRING
}
The authenticationProtocol field is an integer containing the Authen-
tication-Protocol number for PAP, c023 (hex). The name is an octet
string identifying the user to be authenticated. The password is an
octet string providing the user's password.
4.2. PPP Authentication Response
If a server implements this extension, then when the request is made
it will return an LDAP PDU containing an ExtendedResponse. An LDAP
ExtendedResponse is defined as follows:
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
responseName [0] LDAPOID OPTIONAL,
response [1] OCTET STRING OPTIONAL
standardResponse [2] LDAPResult }
The responseName field contains the same string as that present in the
PPP Authentication request. The response field is absent. The server
MUST set the resultCode of the standardResponse to either success or
one of the other values outlined below.
4.3. Error Messages
If the operation was successful, the errorCode field in the standard-
Response part of an ExtendedResponse will be set to success.
In case of an error, the errorCode field will contain an appropriate
value. If the authentication is not successful (due either to invalid
credentials or an invalid userName), the errorCode field will contain
the invalidCredentials result code. If the authentication protocol
Aboba [Page 5]
INTERNET-DRAFT 19 November 1997
given by authenticationProtocol could not be located, the errorCode
field will contain the protocolError result code. If the authentica-
tion protocol is not permitted, the errorCode field will contain
strongAuthRequired. If the requester does not have permission to per-
form the PPP authentication, the errorCode field will contain insuffi-
cientAccessRights. If the server does not do PPP authentication, but
knows another server that does, the errorCode field will contain
referral. If There is a major problem with PPP authentication, or the
server is shutting down the errorCode field will contain unavailable.
If the server is overloaded, the errorCode field will contain busy.
If a server does not implement this extension, it will return an LDAP
PDU containing an ExtendedResponse, which contains only the standard-
Response element (the responseName and response elements will be
absent). The LDAPResult element will indicate the protocolError
result code.
5. Security considerations
Enabling an LDAP-based directory service to perform PPP authentication
operations in an efficient manner may result in a number of security
threats, including password guessing attacks and sniffing attacks.
In order to prevent a rogue RADIUS server from initiating password
guessing attacks, it is desirable for an implementation to close a
connection after a number of consecutive authentication failures.
In order to prevent sniffing of passwords, where PAP authentication is
being used for transmission of cleartext passwords, the RADIUS server
MUST seek to ensure confidentiality by using SSL/TLS or IPSEC. An LDAP
server receiving a PAP authentication request representing a cleartext
password without confidentiality services in place MUST return an
error message.
6. Acknowledgments
Thanks to Gurdeep Singh Pall and Narendra Gidwani of Microsoft for
useful discussions of this problem space.
7. References
[1] W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access Pro-
tocol." RFC 1777, March 1995.
[2] "Information Processing Systems - Open Systems Interconnection -
The Directory: Overview of Concepts, Models and Service." ISO/IEC JTC
1/SC21, International Standard 9594-1, 1988.
[3] "Information Processing Systems - Open Systems Interconnection -
The Directory: Selected Object Classes." Recommendation X.521 ISO/IEC
JTC 1/SC21, International Standard 9594-7, 1993.
Aboba [Page 6]
INTERNET-DRAFT 19 November 1997
[4] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory
Access Protocol (v3): Attribute Syntax Definitions. " Internet Draft
(work in progress), draft-ietf-asid-ldapv3-attributes-08.txt, Critical
Angle, Isode, Netscape, October 1997.
[5] Y. Yaacovi, M. Wahl, T. Genovese, "Lightweight Directory Access
Protocol (v3): Extensions for Dynamic Directory Services. " Internet
Draft (work in progress), draft-ietf-asid-ldapv3-dynamic-06.txt,
Microsoft, Critical Angle, September 1997.
[6] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authentica-
tion Dial In User Service (RADIUS)." RFC 2138, Livingston, Merit, Day-
dreamer, April 1997.
[7] C. Rigney. "RADIUS Accounting." RFC 2139, Livingston, April
1997.
[8] C. Rigney, W. Willats. "RADIUS Extensions." Work in progress,
draft-ietf-radius-ext-01.txt, Livingston, June 1997.
[9] R. Rivest, S. Dusse. "The MD5 Message-Digest Algorithm", RFC
1321, MIT Laboratory for Computer Science, RSA Data Security Inc.,
April 1992.
[10] P. Calhoun, A. C. Rubens, B. Aboba. "Extensible Authentication
Protocol Support in RADIUS." Internet Draft (work in progress),
April, 1997, draft-ietf-radius-eap-02.txt, 3Com, Merit Network,
Microsoft.
[11] L. J. Blunk, J. R. Vollbrecht. "PPP Extensible Authentica-
tion Protocol (EAP)." Work in progress, draft-ietf-pppext-eap-
auth-02.txt, Merit Network, Inc., June, 1996.
[12] D. Carrel, L. Grant. "The TACACS+ Protocol Version 1.77." Work
in progress, draft-grant-tacacs-01.txt, Cisco Systems, October, 1996.
[13] Simpson, W., Editor. "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, DayDreamer, July 1994.
[14] Simpson, W. "PPP Challenge Handshake Authentication Protocol
(CHAP)", RFC 1994, DayDreamer, August 1996.
[15] B. Lloyd, Simpson, W. "PPP Authentication Protocols", RFC 1334,
L&A, DayDreamer, October 1992.
[16] B. Aboba, "Lightweight Directory Access Protocol (v3): Schema for
the Remote Access Dialin User Service (RADIUS) " Internet Draft (work
in progress), draft-aboba-radius-01.txt, Microsoft, November 1997.
[17] B. Aboba, "Lightweight Directory Access Protocol (v3): Dynamic
Attributes for the Remote Access Dialin User Service (RADIUS)" Inter-
net Draft (work in progress), draft-aboba-dynradius-01.txt, Microsoft,
November 1997.
Aboba [Page 7]
INTERNET-DRAFT 19 November 1997
[18] M. Wahl, T. Hoews, S. Kille, "Lightweight Directory Access Proto-
col (v3)." Internet Draft (work in progress), draft-ietf-asid-proto-
col-08.txt, Critical Angle, Netscape, Isode, October 1997.
[19] J. Hodges, R.L. Morgan, M. Wahl, "Lightweight Directory Access
Protocol (v3): Extension for Transport Layer Security." Internet Draft
(work in progress), draft-ietf-asid-ldapv3-tls-01.txt, Stanford, Crit-
ical Angle, June 1997.
[20] Y. Yaacovi, M. Wahl, T. Genovese, "Lightweight Directory Access
Protocol: Dynamic Attributes." Internet Draft (work in progress),
draft-ietf-asid-dynatt-00.txt, Microsoft, Critical Angle, July 1997.
8. Authors' Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 425-936-6605
EMail: bernarda@microsoft.com
Aboba [Page 8]