LDAP strong authentication

John Gardiner Myers (jgm+@CMU.EDU)
Tue, 20 Jun 1995 18:42:10 -0400 (EDT)

Here is a quick strawman proposal for adding strong authentication to
LDAP, using the IMAP authentication work. I'm somewhat new to ASN.1,
please pardon and correct any stupid errors there.

Bind2Request ::= [APPLICATION 17] LDAPString

Bind2Respones ::= [APPLICATION 18] CHOICE {
result [0] LDAPResult,
challenge [1] OCTET STRING
}

Bind2Continuation ::= [APPLICATION 19] CHOICE {
answer [0] OCTET STRING,
quit [1] NULL
}

The parameter of the Bind2 request is an IMAP4 authentication
mechanism, such as defined by RFC 1731. Any use of the string "imap"
used in a server authentication identity in the definition of an
authentication mechanism is replaced with the string "ldap".

The Bind2 request indicates an authentication mechanism to the server.
If the server supports the requested authentication mechanism, it
performs an authentication protocol exchange to authenticate and
identify the user. Optionally, it also negotiates a protection
mechanism for subsequent protocol interactions. If the requested
authentication mechanism is not supported, the server should return a
Bind2Response with a result of authMethodNotSupported.

The authentication protocol exchange consists of a series of server
challenges and client answers that are specific to the authentication
mechanism. When a server returns a Bind2Response with a challenge,
the client answers with a Bind2Continuation. If the client wishes to
cancel an authentication exchange, it should issue a Bind2Continuation
with a quit. If the server receives such an answer, it must reject
the Bind2 request by sending a Bind2Response with a result of
inappropriateAuthentication.

[Instead of having an explicit quit continuation, could have the
client abort by sending a Bind2Request, BindRequest, or UnbindRequest]

A protection mechanism provides integrity and privacy protection to
the protocol session. If a protection mechanism is negotiated, it is
applied to all subsequent data sent over the connection. The
protection mechanism takes effect immediately following the
Bind2Continuation that concludes the authentication exchange for the
client, and the Bind2Response of the success response for the server.
Once the protection mechanism is in effect, the BER encoded stream of
requests and responses is processed into buffers of ciphertext. Each
buffer is transferred over the connection as a stream of octets
prepended with a four octet field in network byte order that
represents the length of the following data. The maximum ciphertext
buffer length is defined by the protection mechanism.

The server is not required to support any particular
authentication mechanism, nor are authentication mechanisms
required to support any protection mechanisms. If the server returns
a Bind2Response with a result other than success, the session remains
unbound and the client may try another
authentication mechanism by issuing another Bind2 Request,
or may attempt to authenticate by using the Bind Request.
In other words, the client may request
authentication types in decreasing order of preference,
with the Bind request as a last resort.

Should the client successfully complete the authentication exchange,
the server issues a Bind2Response containing a result of
success. "user name string" negotiated through the authentication
mechanism is interpreted as the name of the Directory object that the
client wishes to bind as.

[Do we need to send through a protocol version, perhaps by encoding it
in the user name string?]

-- 
_.John G. Myers		Internet: jgm+@CMU.EDU
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up