Subject: RE: low-infrastructure GSS mechanisms?

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

> -----Original Message-----
> From: David Jablon [mailto:[email-masked]]
> Sent: Tuesday, December 22, 1998 8:45 PM
> To: CAT-WG List
> Cc: Theodore Y. Ts'o; Mike Eisler; Paul Leach; Richard B. Ward
> (Exchange); John Linn
> Subject: Re: low-infrastructure GSS mechanisms?
> 
> 
> Regarding password-only methods ...  I'll summarize
> what should be common knowledge to most CAT fanciers:
> 
> 1) Digest is broken by passive and active network brute-force
>    attack.  Why promote it?

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.

However, the question is a non-sequiter. The issue before us is not whether
to promote Digest, it is whether the CAT group should try to fit it into the
GSS framework, in order to make the GSS framework relevant to those who have
alrady decided to use Digest -- such as HTTP/DAV and LDAP, and to those who
are using other simple plaintext password replacement protocols (e.g.
CRAM-MD5 in ACAP, IMAP, etc.) that could (and possibly are heading to) unify
on Digest.

> 
> But even when I take off my promotional hat, I still strongly
> believe that any diligent assessment must first cover the 
> best methods, and then secondarily, measure their
> relative cost and availability.

So, you're in favor of great security -- later, after a diligent assessment.
In the meantime, use plaintext passwords?

The security properties of such as Digest as well known. What is not widely
known with great precision is why better protocols like Kereberos failed to
get deployed. Previous messages in this thread were focussing on that,
because it is relevant to the raison-d'etre of this WG: we spent all this
time on GSS, and it isn't getting used; then along came SASL, and it got
lots of adopters quickly -- what lessons should we draw?

One that I draw is that we don't need new better authentication protocols
now; we need implementations of ones in frameworks that application protocol
implementors will deploy. Let's focus on that.

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] (David P Jablon)
Date: Wed, 23 Dec 1998 16:51:12 -0500

> deployable quickly. It's status as MTI in HTTP/DAV and LDAP is a

A lot of things are better than plaintext, including SPEKE and EKE,
which are also easily implemented and deployed. 

> CRAM-MD5 in ACAP, IMAP, etc.) that could (and possibly are heading to) unify

Unify on Digest?  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.

I fully understand the need to interoperate with legacy
applications.  If people are asking for a GSS interface to Digest,
then sure, go ahead and fit it in.

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.

The implementors already see GSSAPI as overly complex, and
Digest may be seen as a security downgrade to alternative SASL 
mechanisms.  I recall that the AAARG group decided that one
requirement was "plaintext non-equivalence".  While SPEKE and 
EKE-style methods can provide this, there are also other 
improved methods.

Perhaps more would be interested in the benefits of GSS if it 
could meet their objectives, strong security, with no PKI,
compatible with legacy password databases, etc.

> In the meantime, use plaintext passwords?

No need to twist my words.  Each software vendor makes their 
own assessment.  My concern is with giving them a standard 
that provides good choices.  

> lots of adopters quickly -- what lessons should we draw?

Some lessons are clear.  They want increased security without greatly
increased infrastructure.  The SASL movement seems a valid response
to an inadequate set of methods provided by GSS and other standards.
There was certainly some mis-understanding of GSS,
perhaps due to its complexity, and I'm sure there was also
some NIH-syndrome as well.

> now; [...]

I disagree.  Why wait?

>[...]  we need implementations of ones in frameworks that application protocol

I completely agree with this part.

Implementors want a simpler framework than GSS at the API level.
Complexity under the covers is less relevant,
as long as implementations are widely available, affordable,
and their security and infrastructure objectives are met.

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.

GSS permits choice.  For implementors to want to use it,
the API should be as simple as possible, and the set of 
choices must meet (or even exceed) their technical needs
and security objectives.

-- David

------------------------------------------------------
David P. Jablon
Integrity Sciences, Inc.
[email-masked]
<http://world.std.com/~dpj/>