Subject: LDAP service name

From: Chris Newman <[email-masked]>
Date: Thu, 12 Feb 1998 15:34:21 -0800 (PST)

Profiling requirement 1 of the SASL specification (RFC 2222, section 4)
does not seem to be met by the current LDAP SASL profile.

In particular, you need to specify a service name for use with ldap and
register it with IANA at the GSSAPI service registry:

 <http://www.isi.edu/in-notes/iana/assignments/gssapi-service-names>

The concept of a "service name" is used by GSSAPI, SASL, Kerberos and
SCRAM-MD5.  When different services have different security risks, it's
important that the server-side credentials are managed on a per-service
basis.  In addition, users occasionally want different passwords for
different services and the service name creates the distinction.

You might also want to use "host" as a fallback service name if the ldap
service name isn't available.  This what ftp security does (RFC 2228,
appendix I).

		- Chris

---

From: "John Myers" <[email-masked]>
Date: Tue, 17 Feb 1998 20:06:17 -0800

> service name isn't available.  This what ftp security does (RFC 2228,

No other SASL profile specifies a fallback service name, and I would
strenuously recommend against LDAP doing so.  FTP security does not use
SASL, and it is thus not a relevant example.

A protocol's profile of SASL is too high a layer to specify "host"
service fallback.  Specifying service name fallback at this layer will
cause SASL mechanisms which ignore the profile's service name to be
attempted twice, possibly with repeated user interaction, whenever
authentication using that mechanism fails.

The correct place to put this fallback is in the Kerberos KDC and the
part of the Kerberos library that obtains the servers private key. 
Given that Kerberos implementations have botched this and the next layer
up (GSSAPI) has ignored this issue, the next best layer to address this
is with a SASL mechanism.  Define a new SASL mechanism with a new name
which is identical to the current GSSAPI mechanism except in that it
ignores the protocol profile's service name and passes the fixed string
"host" down to GSSAPI.

---

From: "John Myers" <[email-masked]>
Date: Tue, 17 Feb 1998 20:06:17 -0800

Date: Tue, 17 Feb 1998 20:06:17 -0800
From: "John Myers" <[email-masked]>
To: IETF LDAP Extensions WG <[email-masked]>, [email-masked]
Subject: Re: LDAP service name
Sender: [email-masked]

Date: Thu, 12 Feb 1998 15:34:21 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: LDAP service name
To: IETF LDAP Extensions WG <[email-masked]>
Cc: [email-masked]
Reply-to: IETF LDAP Extensions WG <[email-masked]>
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

		- Chris

Date: Mon, 2 Feb 1998 12:06:30 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: Call for volunteers: Moving SASL to draft status (fwd)
To: Chris Newman <[email-masked]>
cc: Steve Hole <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Mon, 02 Feb 1998 10:29:45 -0800 (PST), Chris Newman wrote:
> On Mon, 26 Jan 1998, Steve Hole wrote:
> > Hang on a minute.   The issue is that a client and server GSSAPI will
> > not interoperate if they implement different underlying mechanisms.  If
> > so then: (1) this will probably not happen often in practise because
> > the authentication infrastructure an organization uses is usually
> > controlled by the organization and (2) if it does happen, then
> > authentication fails for a valid reason.

This seems to be based on the notion that this can be configured in the
application (client and server) by the organization.  I don't think that this
is a valid assumption.

GSSAPI is not like c-client, which carefully keeps the application at a
distance from its drivers.  GSSAPI only takes you so far, then you start
having to have knowledge about the actual authentication infrastructure.

Think in terms of a world where most people do not build their own binaries.

Both my client and (especially!) server code have K5 knowledge.  The client
code may function with something other than K5, although you would definitely
have to rebuild and the error handling won't be right without source code
changes.  The server code will definitely not function without source code
changes.

My code isn't the only offender, either.

> If we wait, I suspect GSSAPI will mean "Kerberos 5 GSSAPI mechanism."
> That will only cause problems for GSSAPI mechanisms other than Kerb5.

This has already happened.  It's too late to prevent it.

It isn't too late to get the responsible parties to transition to a different
name for "Kerberos 5 GSSAPI mechanism" but time is rapidly running out.

From: "Larry Osterman (Exchange)" <[email-masked]>
To: [email-masked]
Subject: RE: OK to send e-mail?
Date: Mon, 2 Feb 1998 10:20:01 -0800 
Sender: [email-masked]

Oh great - spamboy is hitting SASL now....

Larry Osterman
Via Exchange 5.5 on Larryo-Laptop.dns.microsoft.com.
Please notify the sender of any difficulties.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Saturday, January 31, 1998 4:20 AM
To: [email-masked]
Subject: OK to send e-mail?

OK to send an e-mail to [email-masked]? 

Date: Mon, 02 Feb 1998 10:29:45 -0800 (PST)
From: Chris Newman <[email-masked]>
Subject: Re: Call for volunteers: Moving SASL to draft status (fwd)
To: Steve Hole <[email-masked]>
Cc: [email-masked], [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

On Mon, 26 Jan 1998, Steve Hole wrote:
> On Fri, 23 Jan 1998 16:11:48 -0800 John Gardiner Myers <[email-masked]> 
> wrote:
> > (2) sounds like a very good idea.  GSSAPI mechanism implementations
> > which use different underlying GSSAPI mechanisms won't interoperate. 
> > Defining a separate SASL mechanism for each underlying GSSAPI mechanism
> > will allow this to be negotiated at the SASL layer.  
> > 
> > When SNEGO finally arrives, we can have GSSAPI-SNEGO.  I don't think
> > GSSAPI-using-Kerb5 interoperates with GSSAPI-using-SNEGO-using-Kerb5
> > anyway, so having a GSSAPI-SNEGO which can negotiate Kerb5 be separate
> > from GSSAPI-Kerb5 is a good thing.
> > 
> > We can either define a new GSS-KERB5 only if we act quickly, otherwise
> > we'd have to declare that the name GSSAPI refers to GSSAPI using
> > Kerberos V5.
> > 
> > Do we have a quick consensus to change this?
> 
> Hang on a minute.   The issue is that a client and server GSSAPI will
> not interoperate if they implement different underlying mechanisms.  If
> so then: (1) this will probably not happen often in practise because
> the authentication infrastructure an organization uses is usually controlled
> by the organization and (2) if it does happen, then authentication fails for a 
> valid reason.

The reason I proposed this change initially is that I dislike multi-level
negotiations.  Suppose you have a GSSAPI client which supports both
Kerberos-5 and public key?  When you try Kerberos-5 and it fails with
invalid messages for the Kerberos-5 GSSAPI mechanism, do you retry GSSAPI
to see if the server is using the public key or do you fall back to a
different SASL mechanism since GSSAPI failed?  It makes the code more
complicated to deal with cases like this.

> I am not totally set in this position.   The GSSAPI thing is messy.   I just
> wish that we had some more experience with it before we start mucking about
> this way.   At this time I don't really see all that big a win in doing this,
> but that could very well change in the near future as we try to deploy our
> implementation.

If we wait, I suspect GSSAPI will mean "Kerberos 5 GSSAPI mechanism."
That will only cause problems for GSSAPI mechanisms other than Kerb5.

		- Chris