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?

-Rich

-----Original Message-----
From: Linn, John [mailto:[email-masked]]
Sent: Monday, December 21, 1998 12:41 PM
To: 'CAT-WG List'
Subject: low-infrastructure GSS mechanisms?

CAT fanciers: 

At several points during the Orlando IETF meeting, culminating at the EAP
BOF on Friday morning, I heard interest expressed in the availability of
"low-infrastructure" mechanisms under GSS-API.  
==========================================================================
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: "Theodore Y. Ts'o" <[email-masked]>
Date: Mon, 21 Dec 1998 20:27:39 -0500

From: "Richard B. Ward (Exchange)" <[email-masked]>
   Date: Mon, 21 Dec 1998 15:56:44 -0800

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.

---

From: David Jablon <[email-masked]>
Date: Tue, 22 Dec 1998 23:44:41 -0500

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?

2) DH-assisted Digest, as described by Ted Ts'o, is better, but
   still vulnerable to active brute-force attack.

3) Several strong methods exist (EKE, SPEKE, SRP, etc.) which
   prevent both unconstrained active and passive network attack,
   and which consume no more power than ordinary DH.

Ted is right that patents cover some of these, but no one
vendor dominates.  Anyone familiar with my work knows why
I prefer at least one of the patented methods.

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.

I'll address some fine points below ...

At 08:27 PM 12/21/98 -0500, Ted Ts'o wrote:
> Yes, [Digest is] basically what people were talking about, although some
>	All my customers have is a Unix /etc/passwd file [...]
>

I prefer to give those "apps" people the benefit of doubt, and
agree that preserving compatibility with /etc/passwd and other
legacy formats may be a valid requirement, in some cases.

This requirement can be also be easily addressed by SPEKE,
EKE, and related methods, even better than by vanilla DH.

> confidentiality and data integrity services in addition to merely

This is still open to brute-force attack by the middleman.
Password-authenticated DH prevents this.

> problems in the protocol on the cryptography@c2 list back then.

In the interest of completeness and accuracy, I believe the
valid issues which Marcus raised w.r.t. SRP back in Feb. 98
on the cryptography@c2 list were directed more to Tom Wu's
style and presentation, rather than to the technical merits
of the method. I was not privy to the Orlando conversation.

The really fruitful public disection of SRP took place half-a-year
earlier on sci.crypt, which resulted in SRP-3.  As far as I know,
this version has not been broken, to the dismay of some of
the critics.

-- dpj

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

---

From: Mike Eisler <[email-masked]>
Date: Wed, 23 Dec 1998 07:04:17 -0800 (PST)

> legacy formats may be a valid requirement, in some cases.

I agree.

> EKE, and related methods, even better than by vanilla DH.

I'll expose my ignorance here, and ask how does EKE address the /etc/passwd
requirement?

Schneir's description of EKE states that both parties know the common secret.
The problem is that the server with access to /etc/passwd (or /etc/shadow),
doesn't know the user's password, it only knows the the UNIX password hash.
The UNIX password hash can't be the shared secret, because despite the
existance of /etc/shadow, UNIX password hashes tend to be easily determined,
since many of the "apps" people are running a directory service like NIS.

	-mre

---

From: [email-masked] (David P Jablon)
Date: Wed, 23 Dec 1998 14:41:57 -0500

> I'll expose my ignorance here, and ask how does EKE address the /etc/passwd

It depends on how you state the requirement.  I'll explain
how EKE/SPEKE performs better than DH or clear-text when no
other database format can be used, and when there's just no
other basis to encrypt or authenticate the channel.  

> [In EKE,] both parties know the common secret.
 
In cases where the hashed password is widely available to everyone,
via NIS or otherwise, there's obviously no compelling reason to 
stop brute-force attack merely within the verification protocol.
With the requirement that /etc/passwd is world-readable,
the problem seems intractible.

But if there's any limitation on the distribution of the hashed 
passwords, SPEKE or EKE can use the hashed-password to authenticate 
the tunnel for transmission of the password.  While one can 
always do better with a new stored verifier format,
this is better than any unauthenticated or unencrypted alternatives.

------------------------------------------------------
David P. Jablon
Integrity Sciences, Inc.
[email-masked]