Subject: Re: low-infrastructure GSS mechanisms?

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Mon, 21 Dec 1998 20:58:17 -0500

From: Paul Leach <[email-masked]>
   Date: Mon, 21 Dec 1998 17:39:04 -0800

   I know that the people who want SASL think that SSL and Kerberos are too
   heavyweight (big implementations) -- they have resisted making those
   mandatory-to-implement (MTI) in LDAP WG and other WGs on that basis. Hence,
   I predict that a DH based scheme would also be judged too heavyweight for
   the general purpose "eliminate plaintext passwords MTI" scheme. 

If the folks who didn't like SSL didn't like it merely because of "big
implementations", there's no reason that a D-H scheme has to be all that
large.  So if it's just that, all that should be needed to make their
resistence go away is for someone to implement a small, no-nonsense D-H
and make it available as freeware for folks to put into the their
products.

There are of course other definitions of "heavyweight" that people might
be complaining about:

	* Infrastructure requiring (Kerberos and SSL if you're doing
		client certs)
	* Hard to implement (which we can trump with a good Open Source
		reference implementation)
	* Time to authenticate (SSL)

We can't do much about the authentication time --- that's inherent in PK
based solutions.  But for many applications, this shouldn't be an issue,
since the context establishment is only done at the start of the
connection.  There are exceptions of course, such as badly designed
protocols like HTTP --- a lot of the hair in SSL is performance hacks to
get around that the fact that you need to make repeated TCP connections,
and thus mitigate the cryptographic (but not the TCP slow start)
implications of such a bad design choice.

I was assuming a simple D-H scheme that didn't make such accomodations,
which should be much easier to make to be lightweight.

						- Ted
==========================================================================
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: Paul Leach <[email-masked]>
Date: Mon, 21 Dec 1998 17:39:04 -0800

Digest authentication is pretty lightweight. See
<draft-leach-digest-sasl-01.txt>.

I know that the people who want SASL think that SSL and Kerberos are too
heavyweight (big implementations) -- they have resisted making those
mandatory-to-implement (MTI) in LDAP WG and other WGs on that basis. Hence,
I predict that a DH based scheme would also be judged too heavyweight for
the general purpose "eliminate plaintext passwords MTI" scheme. Also, DAV
and LDAP and HTTP will use Digest as the MTI, so lots of folks will need it
to support these protocols -- why not use it for others as well.

I think that an SSL GSS definition is a good idea, independently of whether
it is MTI for any application protocol. And it does permit use of
/etc/passwd files without password changes; for those for whom this is a
hard requirement, it may be the simplest course, because the needed pieces
all exist -- a new protocol for just this one reason would be hard to
justify, IMHO.

> -----Original Message-----
> From: Theodore Y. Ts'o [mailto:[email-masked]]
> Sent: Monday, December 21, 1998 5:28 PM
> To: Richard B. Ward (Exchange)
> Cc: 'Linn, John'; 'CAT-WG List'; Paul Leach
> Subject: Re: low-infrastructure GSS mechanisms?
> 
> 
>    From: "Richard B. Ward (Exchange)" 
> <[email-masked]>
>    Date: Mon, 21 Dec 1998 15:56:44 -0800
> 
>    If we can take the term "Low Infrastructure" to mean 
> essentially "I want
>    this to work with the client and server sides knowing only 
> the password (or
>    a hash thereof) and the user's name", then I suggest 
> taking a closer look at
>    Digest authentication.  Paul (on the cc: line) has been 
> involved in the
>    definition of the Digest exchanges, and we're trying to 
> keep an opening
>    available for a GSS interpretation of Digest.  Paul, can 
> you forward some
>    references for Digest to the list?
> 
> Yes, that's basically what people were talking about, although some
> people in the apps area have demanded even lower 
> infrastrcture, namely:
> 
> 	All my customers have is a Unix /etc/passwd file and I can't be
> 	bothered to design a transition code in my server to capture the
> 	plaintext password the next time it gets used and convert it
> 	into some other password db format (whether it be Kerberos or
> 	digest authentication).
> 
> If we think this is a valid requirement (I don't, but some 
> folks in the
> AARG bof did), that would speak towards using a diffie-helman 
> protected
> tunnel and sending the ASCII password in the encrypted 
> tunnel.  This is
> of course subject to a man-in-the-middle attack, though.
> 
> 
> What I would suggest as a better approach would be to use 
> something like
> digest authentication, but to do so under a diffie-helman 
> tunnel, and to
> include the D-H parameters in the hash to protect against
> man-in-the-middle.  This would allow the mechanism to provide
> confidentiality and data integrity services in addition to merely
> authenticating the user.
> 
> For completeness sake, there's also Thomas Wu's SRP (Secure Remote
> Password), but that's a patented algorithm, which will create 
> problems,
> and Marcus Leach mentioned to me at the Orlando IETF that if it's the
> same protocol which was presented a year or so ago, he demonstrated
> problems in the protocol on the cryptography@c2 list back 
> then.  In any
> case, there are workable non-patented alternatives, so I don't see the
> point of pursuing a patented technology at this point for
> standardization.
> 
> 						- Ted
> 
> P.S.  Doug Engbert announced on the krbdev list that he had recently
> coded a SSL GSSAPI mechanism.  I don't have more information about
> exactly which SSL mode it uses, but it sounds interesting.
>