Subject: RE: low-infrastructure GSS mechanisms?

From: Paul Leach <[email-masked]>
Date: Wed, 23 Dec 1998 14:22:13 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, December 23, 1998 1:51 PM
> To: CAT-WG List; Paul Leach
> Cc: John Linn; Richard B. Ward (Exchange); Mike Eisler; 
> Theodore Y. Ts'o
> Subject: Re: low-infrastructure GSS mechanisms?
> 
> 
> 
> I wrote:
> >> 1) Digest is broken by passive and active network brute-force
> >>    attack.  Why promote it?
> 
> Paul Leach wrote:
> > Because it is better than plaintext passwords and it is 
> implementable and
> > deployable quickly. It's status as MTI in HTTP/DAV and LDAP is a
> > fait-accompli.
> 
> A lot of things are better than plaintext, including SPEKE and EKE,
> which are also easily implemented and deployed.

But they haven't got to the point that consensus has been reached that they
_will_ be deployed. Digest has.

> I thought part of the appeal of GSS was in its
> ability to switch underlying methods, and not in forcing
> a single unified consensus on a particular method.

GSS has this capability. But someone still needs to implement any
_particular_ authentication method as a GSS mechanism. And if
implementations of popular methods as GSS mechanisms do not exist, it
reduces the attractives of GSS as a framework.

Once people have deployed the framework as a side effect of getting some
mechanisms that they need, _then_ one has the ability to easily switch
mechanisms -- not before.

> 
> But if you want to provide a method that's attractive to 
> implementors of new applications, you'll want to provide 
> more than Digest alone.

It turns out the the developers of new application protocols probably care
more about ease of use, ease of implementation, and size of implementation
than "attractiveness" of auth methods from a security point of view. As far
as I can tell, for many (not all) of them, if the IESG weren't demanding it,
many new protocols would still be using plaintext passwords.

> 
> The implementors already see GSSAPI as overly complex,

I have heard the same. However, the SASL APIs, which are easy to use, can be
implemented in terms of GSS, which takes care of the "ease of use" issue.
That only leaves the issue of implementation size -- which is where Kerberos
has had issues winning acceptance.

 and
> Digest may be seen as a security downgrade to alternative SASL 
> mechanisms.

I've seen no evidence of that, for SASL mechanisms that people really plan
to use.

  I recall that the AAARG group decided that one
> requirement was "plaintext non-equivalence".

AAARG died from being overambitious. Its requirement were never accepted by
any application protocol WG.

[...]

> There's surely no consensus in the apps community on
> objectives.  But in two distinct areas, Digest falls
> short:  It doesn't perform optimally with existing databases,
> and it doesn't offer plaintext non-equivalence.

Which is a non-requirement for any application protocol considering using it
as a universal, fast time to implement and deploy, high performance, MTI
plaintext password replacement in order to get the IESG to approve their
protocol for Proposed Standard status.

I.e., there is consensus on Digest being good enough for now.

If you want to create or standardize on a new authenticate method, form a
WG. Don't toss it in to a discussion of why more people aren't using GSS --
it isn't the reason, and it just confuses the issues.

Paul

==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: [email-masked]
Date: Wed, 23 Dec 1998 17:24:21 -0800

I think there is a need to provide applications with a way to upgrade to 
stronger authentication methods as these infrastructures become available.  SASL
does provide this in a way, but I do not think the SASL API's are quite standard
so I'm not sure if an application could easily switch SASL toolkits to obtain 
support for stronger auth.  GSSAPI on the other hand does provide a standard API
that should allow you to use a different mechanism with a minimal amount of 
work. In practice the amount of work varies, depending on how the application 
uses the API and how the mechanisms are implemented changing mechanism can be a 
little tricky.  Has a standard SASL API been published?

Joe
______________________________ Reply Separator _________________________________
Subject: RE: low-infrastructure GSS mechanisms?
Author:  paulle ([email-masked]) at internet,shar
Date:    12/23/98 2:22 PM

     

     

     

     
 and

     
     
[...]

     

Paul

---

From: John Stidd <[email-masked]>
Date: Mon, 28 Dec 1998 12:24:59 PST

Joe,

I don't think I understand the mention of the SASL APIs in Paul Leach's
message.  SASL "is a method for adding authentication support to
connection-based protocols", according to RFC 2222.  All of the technical
RFCs that reference SASL are protocol definitions (RFCs 2229, 2244, 2245,
and LDAP).  These RFCs state how they support SASL.  RFC 2222 (SASL)
itself supports GSS as a "mechanism", and describes how the GSS-API is
used by the client and server to implement the SASL support for
authentication.  In that case, the API for SASL would be GSS.  For other
SASL mechanisms, the SASL API would be that of the mechanism, which might
or might not be a standard.  The currently supported SASL mechanisms are
listed in
<bigger>ftp://ftp.isi.edu/in-notes/iana/assignments/sasl-mechanisms.
These include Kerberos v4, GSS, S-Key, and others, many of which are
protocol definitions with no API.  I hope this is helpful.

John

</bigger>

At 05:24 PM 12/23/98 PST, [email-masked] wrote: