Subject: RE: low-infrastructure GSS mechanisms?

From: Paul Leach <[email-masked]>
Date: Mon, 28 Dec 1998 13:44:07 -0800

4 or 5 developers who have implemented SASL mechanisms have also created
APIs to access generic SASL mechanisms; there was a lunch BOF of them to
discuss how/whether to merge and propose as an informational RFC at the
Orlando IETF.

-----Original Message-----
From: John Stidd [mailto:[email-masked]]
Sent: Monday, December 28, 1998 12:25 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: low-infrastructure GSS mechanisms?

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
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 

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

>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 

>> -----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] 

>========================================================================== 

>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] 

> ==========================================================================
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]

==========================================================================
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: Tue, 29 Dec 1998 17:20:18 -0800

Why just an informational RFC and not in the standards track? 

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

-----Original Message-----
From: John Stidd [mailto:[email-masked]] 
Sent: Monday, December 28, 1998 12:25 PM
To: [email-masked]
Cc: [email-masked]; [email-masked] 
Subject: RE: low-infrastructure GSS mechanisms?

Joe, 

John 

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

     
SASL 
     
standard 
     
obtain 
     
API 

application 
     
be a 

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

it, 

     

     
be 

Kerberos 

     

     

     

     

     

     

     

it