[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
LDAP extension draft for GSSAPI protection of session data
I plan to submit this draft as an Internet draft. Any comments or suggestions
are welcome.
Jonathan
INTERNET-DRAFT Jonathan Trostle
draft-ietf-ldapext-ldapv3-gss-protect-00.txt Cisco Systems
expires January, 1999
Extension to LDAP V3 For GSS Based Data Protection
0. Status Of This Memo
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 docu-
ments at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as ``work in pro-
gress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Sha-
dow Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Comments and suggestions on this document are encouraged. Comments
on this document should be sent to the LDAPEXT working group
discussion list:
ietf-ldapext@netscape.com
This document expires in January 1999.
1. Abstract
This document defines an extension to the LDAP V3 protocol
specification (RFC 2251) [LDAPv3] to enable GSSAPI Wrap tokens
[GSSAPI] to be encapsulated in LDAP extended request and extended
response messages. The GSSAPI Wrap tokens provide data session
integrity and optionally, confidentiality.
2. Motivation
Through SASL [SASL], GSSAPI security mechanisms can be incorporated
into LDAPv3 to provide authentication of LDAP entities. For some
environments, protection of the LDAP session data is also desirable.
[AuthMeth] specifies incorporation of TLS [TLS] as a means to
provide this data protection. The aim of the present draft is to
enable additional security mechanisms compatible with the framework
in [AuthMeth] to be used to provide LDAP v3 data session protection.
An LDAP client can use the SASL GSSAPI mechanism to initiate a GSSAPI
data protected session; if the server does not support this option,
then the client can use the StartTLS [StartTLS] option to initiate a
TLS protected session.
3. The Extension
A LDAP client creates a GSSAPI Wrap Token according to the particular
GSSAPI security mechanism in use for the connection. The LDAP data
is the data portion of the GSSAPI Wrap Token. This GSSAPI Wrap Token
is then encoded as an OCTET STRING in the requestValue field of
an Extended Request. An LDAP ExtendedRequest is defined as follows:
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL }
The requestName field is set to the OID:
[in the process of obtaining an OID]
An LDAP server responds to such an extended request with an LDAP
ExtendedResponse message:
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
responseName [0] LDAPOID OPTIONAL,
response [1] OCTET STRING OPTIONAL,
standardResponse [2] LDAPResult }
The extended response MUST contain a responseName field which MUST be
set to the same string as that present in the client extended request.
The standardResponse field will be set to success. The response field
contains the LDAP data, encapsulated in the GSSAPI Wrap Token and then
encoded into an OCTET STRING. The client and server must also be
prepared to accept GSSAPI mechanism specific protocol messages (e.g.,
error messages); these messages are encoded as OCTET STRINGS in either
the requestValue field of the ExtendedRequest or the response field of
the ExtendedResponse messages. The encapsulation continues until
either the LDAP connection is closed or another (encapsulated) bind
message is sent. If another bind message is sent, the security options
are re-negotiated based on the mechanism specified in the new sequence
of bind messages. These bind messages are protected with the existing
GSSAPI mechanism protection features.
If the LDAP client initiates the SASL GSSAPI mechanism using the
GSSAPI snego [Snego] mechanism, and the LDAP server accepts
a proposed GSSAPI security mechanism from the client's list of
security mechanisms, then the snego confidentiality and integrity
context flags will apply to the selected mechanism (for each of
confidentiality/integrity services that the mechanism supports).
In this case, the LDAP entities must be prepared to generate and
accept the extended requests and replies. In the snego case, the
additional SASL exchange that is used to negotiate confidentiality
and integrity options will not be sent.
4. References
[AuthMeth] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan. "Authenti-
cation Methods for LDAP". INTERNET-DRAFT, Work In Pro-
gress. draft-ietf-ldapext-authmeth-02.txt.
[LDAPv3] M. Wahl, S. Kille and T. Howes. "Lightweight Directory
Access Protocol (v3)". RFC 2251.
[Snego] E. Baize, D. Pinkas. "The Simple and Protected GSS-API
Negotiation Mechanism". INTERNET-DRAFT, Work In Progress.
draft-ietf-cat-snego-09.txt.
[SASL] J. Myers. "Simple Authentication and Security Layer
(SASL)". RFC 2222.
[TLS] Tim Dierks, C. Allen. "The TLS Protocol Version 1.0".
INTERNET-DRAFT, Work In Progress. draft-ietf-tls-
protocol-05.txt.
[GSSAPI] J. Linn. "Generic Security Service Application Program
Interface, Version 2". RFC 2078.
[StartTLS] J. Hodges, RL Morgan, M. Wahl, "LDAPv3 Extension for
Transport Layer Security". INTERNET DRAFT, Work In
Progress. draft-ietf-ldapext-ldapv3-tls-00.txt.
5. Acknowledgements
Thanks to John Strassner for some helpful comments.
6. Authors' Addresses
Jonathan Trostle
170 W. Tasman Dr.
San Jose, CA 95134, U.S.A.
Email: jtrostle@cisco.com
Phone: (408) 527-6201