ASID Working Group Bernard Aboba
INTERNET-DRAFT Microsoft
<draft-aboba-ppp-00.txt>
6 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-
ietf-asid-ldapv3-ppp-00.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 believed
that an LDAP extended operation is the appropriate mechanism for pro-
viding this support, since current LDAP security mechanisms do not
support PPP authentication methods. In addition, requiring a BIND and
UNBIND for each authentication results in an unacceptable level of
overhead.
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
Aboba [Page 1]
INTERNET-DRAFT 6 November 1997
user data. In order to simplify user administration, it is desirable
to be able to integrate these services with an LDAP-based directory
service.
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. How-
ever, we believe that this alternative involves an unacceptable level
of overhead, since it requires setting up an SSL/TLS connection for
each incoming request, in addition to requiring a BIND and UNBIND.
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.
It is believed that this approach is more efficient, since the RADIUS
server may use the existing SSL/TLS connection, and need not execute a
BIND and UNBIND request for every authentication.
Aboba [Page 2]
INTERNET-DRAFT 6 November 1997
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
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 {
Aboba [Page 3]
INTERNET-DRAFT 6 November 1997
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
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
Aboba [Page 4]
INTERNET-DRAFT 6 November 1997
Authentication-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
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
Aboba [Page 5]
INTERNET-DRAFT 6 November 1997
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.
[4] M.Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory
Access Protocol (v3): Attribute Syntax Definitions. " Internet Draft
(work in progress), July 1997, draft-ietf-asid-
ldapv3-attributes-06.txt, Critical Angle, Isode, Netscape.
[5] Y. Yaacovi, M. Wahl, T. Genovese, "Lightweight Directory Access
Protocol (v3): Extensions for Dynamic Directory Services. " Internet
Draft (work in progress), May 1997, draft-ietf-asid-ldapv3ext-04.txt,
Microsoft, Critical Angle.
[6] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti-
cation Dial In User Service (RADIUS)." RFC 2138, Livingston, Merit,
Daydreamer, 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-00.txt, Livingston, January, 1997.
[9] R. Rivest, S. Dusse. "The MD5 Message-Digest Algorithm", RFC
Aboba [Page 6]
INTERNET-DRAFT 6 November 1997
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), September, 1997, draft-ietf-asid-ldapv3-radius-00.txt,
Microsoft.
[17] B. Aboba, "Lightweight Directory Access Protocol (v3): Dynamic
Attributes for the Remote Access Dialin User Service (RADIUS)" Inter-
net Draft (work in progress), September, 1997, draft-ietf-asid-
ldapv3-radiusdyn-00.txt, Microsoft.
[18] M. Wahl, T. Hoews, S. Kille, "Lightweight Directory Access Proto-
col (v3)." Internet Draft (work in progress), draft-ietf-asid-proto-
col-06.txt, Critical Angle, Netscape, Isode, 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 7]