[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: LDAP extension draft for GSSAPI protection of session data
It doesn't seem appropriate to keep sending bind messages; the LDAP v3 spec.
states that all previous requests are abandoned when a new bind message is sent.
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 16:40:13 -0700
> MIME-Version: 1.0
>
> 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
> > > > >