[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: LDAP extension draft for GSSAPI protection of session data
Thanks for your efforts, but I do not see where SASL specifies how the data
stream (following initial authentication) tokens are exchanged. Are you saying
that the bare unencapsulated GSS Wrap tokens are sent on the wire?
Jonathan
> X-SMAP-Received-From: outside
> Date: Fri, 31 Jul 1998 19:08:10 -0700 (PDT)
> From: Chris Newman <Chris.Newman@innosoft.com>
> Subject: RE: LDAP extension draft for GSSAPI protection of session data
> To: Bruce Greenblatt <Bgreenblatt@RSA.com>
> Cc: Jonathan Trostle <jtrostle@cisco.com>, ietf-ldapext@netscape.com
> MIME-version: 1.0
> Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
>
> There's a basic misconception that I've been unable to explain properly.
> Let me try once more.
>
> SASL stands for "Simple Authentication and *Security Layer*." So all SASL
> mechanisms which define a security layer (including GSSAPI) automatically
> provide that security layer in LDAP without the need to define new
> extensions. SASL's security layer is much like the one provided by TLS
> except that it's much simpler and tied to the client authentication step.
>
> The GSSAPI SASL mechanism (RFC 2222) exchanges GSSAPI credentials and
> negotiates whether or not session integrity or privacy is desired. And it
> also specifies how the GSS_Wrap() function is used to create a
> protocol-independent SASL security layer.
>
> So RFC 2222 completely specifies how a protocol datastream is encoded
> using GSS_Wrap(), and the LDAP spec specifies at what point after the bind
> exchange this security layer comes into effect. That forms a complete
> specification for an LDAP security layer using GSS_Wrap().
>
> Therefore any protocol defining how to use GSS_Wrap() over LDAP operations
> is redundant with the current standards, unless there is a need to adjust
> the security parameters mid-stream.
>
> - Chris
>