[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: LDAP extension draft for GSSAPI protection of session data
If I follow you, I think that you should rewrite your draft to encapsulate
all of the data in the LDAP Bind in the SaslCredentials field. The
mechanism that is used is the registered string for GSSAPI. Your draft
needs to specify the format of the the GSSAPI stuff in the credentials
field. These fields are already defined in the Bind:
The Bind Request is defined as follows:
BindRequest ::= [APPLICATION 0] SEQUENCE {
version INTEGER (1 .. 127),
name LDAPDN,
authentication AuthenticationChoice }
AuthenticationChoice ::= CHOICE {
simple [0] OCTET STRING,
-- 1 and 2 reserved
sasl [3] SaslCredentials }
SaslCredentials ::= SEQUENCE {
mechanism LDAPString,
credentials OCTET STRING OPTIONAL }
Chris is right that you definitely don't need to define new extended
operations for this purpose, but you're right that the current LDAP RFC
doesn't define how to "wrap" the GSSAPI information into the SaslCredentials
field in the Bind.
Bruce
> -----Original Message-----
> From: Jonathan Trostle [SMTP:jtrostle@cisco.com]
> Sent: Friday, July 31, 1998 4:28 PM
> To: jtrostle@cisco.com; Chris.Newman@INNOSOFT.COM; Bruce Greenblatt
> Cc: ietf-ldapext@netscape.com
> Subject: RE: LDAP extension draft for GSSAPI protection of session
> data
>
> No. Just trying to specify how GSSAPI tokens can be exchanged within the
> LDAP
> protocol. Summarizing:
>
> Suppose you have used the SASL GSSAPI mechanism in LDAP bind messages to
> authenticate LDAP peers and set up some shared keys for message
> protection.
> Now suppose you want to exchange GSSAPI wrap tokens to protect the LDAP
> data.
> These are mechanism dependent; so let's suppose you are using the GSSAPI
> Kerberos V5 mechanism (RFC 1964).
>
> The GSS_Wrap() token (for RFC 1964) has the following format:
>
> Byte no Name Description
> 0..1 TOK_ID Identification field.
> Tokens emitted by GSS_Wrap() contain
> the hex value 02 01 in this field.
> 2..3 SGN_ALG Checksum algorithm indicator.
> 00 00 - DES MAC MD5
>
> 01 00 - MD2.5
> 02 00 - DES MAC
> 4..5 SEAL_ALG ff ff - none
> 00 00 - DES
> 6..7 Filler Contains ff ff
> 8..15 SND_SEQ Encrypted sequence number field.
> 16..23 SGN_CKSUM Checksum of plaintext padded data,
> calculated according to algorithm
> specified in SGN_ALG field.
> 24..last Data encrypted or plaintext padded data
>
>
> The LDAP data goes into the Data field of the Wrap token. Now we have to
> get it
> over to our LDAP peer. Since we are speaking LDAP, we must encapsulate the
> wrap
> token into the LDAP protocol. One way (which I have described in the
> spec.) is
> to encapsulate the wrap tokens into LDAP extended requests and responses.
>
> Jonathan
>
> > X-SMAP-Received-From: outside
> > From: Bruce Greenblatt <Bgreenblatt@RSA.com>
> > To: Jonathan Trostle <jtrostle@cisco.com>, Chris.Newman@INNOSOFT.COM
> > Cc: ietf-ldapext@netscape.com
> > Subject: RE: LDAP extension draft for GSSAPI protection of session data
> > Date: Fri, 31 Jul 1998 13:58:17 -0700
> > MIME-Version: 1.0
> >
> > Jonathan,
> >
> > Is it your expectation that there will be numerous changes during the
> LDAP
> > "session" of the GSSAPI parameters? I'd have thought that once the
> > encryption parameters were set up, then they'd stay the same for the
> life of
> > the session. If this is the case a multi-stage Bind using SASL seems
> likely
> > to accomplish almost all of what you're trying to do.
> >
> > Bruce
> >
> > > -----Original Message-----
> > > From: Jonathan Trostle [SMTP:jtrostle@cisco.com]
> > > Sent: Friday, July 31, 1998 12:06 PM
> > > To: jtrostle@cisco.com; Chris.Newman@INNOSOFT.COM
> > > Cc: ietf-ldapext@netscape.com
> > > Subject: Re: LDAP extension draft for GSSAPI protection of session
> > > data
> > >
> > > Right. Except these spec.'s do not specify how GSSAPI Wrap tokens are
> to
> > > be
> > > carried within the LDAP protocol to secure the LDAP session data. In
> other
> > >
> > > words, they specify only how initial authentication is to occur for
> LDAP
> > > using
> > > GSSAPI.
> > >
> > > Jonathan
> > >
> > > > X-SMAP-Received-From: outside
> > > > Resent-Date: Thu, 30 Jul 1998 08:44:20 -0700 (PDT)
> > > > Date: Thu, 30 Jul 1998 08:44:17 -0700 (PDT)
> > > > From: Chris Newman <Chris.Newman@INNOSOFT.COM>
> > > > Subject: Re: LDAP extension draft for GSSAPI protection of session
> data
> > > > To: Jonathan Trostle <jtrostle@cisco.com>
> > > > Cc: ietf-ldapext@netscape.com
> > > > MIME-version: 1.0
> > > > Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
> > > > Resent-Message-ID: <"kLjpD.0.Vh2.FJ9mr"@glacier>
> > > > Resent-From: ietf-ldapext@netscape.com
> > > > X-Mailing-List: <ietf-ldapext@netscape.com> archive/latest/567
> > > > X-Loop: ietf-ldapext@netscape.com
> > > > Resent-Sender: ietf-ldapext-request@netscape.com
> > > >
> > > > On Wed, 29 Jul 1998, Jonathan Trostle wrote:
> > > > > I did not think that spec. included how the wrapped tokens should
> be
> > > > > transmitted in the LDAP protocol.
> > > >
> > > > RFC 2251 section 4.2.2. 3rd paragraph says when a SASL security
> layer
> > > > starts in LDAP, and RFC 2222 specifies how a SASL security layer is
> > > > formed, and how GSS API is used to negotiate and form a security
> layer.
> > > >
> > > > - Chris
> > > >