[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: LDAP extension draft for GSSAPI protection of session data
But 4.2.1 of RFC 2251 says:
For some SASL authentication mechanisms, it may be necessary for the
client to invoke the BindRequest multiple times. If at any stage the
client wishes to abort the bind process it MAY unbind and then drop
the underlying connection. Clients MUST NOT invoke operations
between two Bind requests made as part of a multi-stage bind.
> -----Original Message-----
> From: Jonathan Trostle [SMTP:jtrostle@cisco.com]
> Sent: Friday, July 31, 1998 4:58 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
>
> 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
> > > > > >