[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
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
> > >