Subject: Re: GSS-API-Easy mechanism

From: [email-masked]
Date: Thu, 04 Mar 99 13:12:04 GMT

> But for a user-chosen password ("Qwertyui"), the threat
> is severely understated.  People are notoriously bad random
> generators.  Furthermore, there's no reliable way to measure
> randomness in a given choice.
[...]
> The documentation problem can be addressed by a clearer
> statement of assumptions.  If it doesn't mandate using a
> generated 48-bit (or larger) random password, it may be
> best to suggest what is likely to happen, given what we
> do know about human behavior.

There was a good paper at NDSS by Thomas Wu called "A Real-World Analysis
of Kerberos Password Security" that addresses this point. Maybe you could
just reference that.
     Mez

==========================================================================
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: Carlisle Adams <[email-masked]>
Date: Thu, 4 Mar 1999 14:50:20 -0500

Hi,

> ----------
> From: 	Theodore Y. Ts'o[SMTP:[email-masked]]
> Sent: 	Tuesday, March 02, 1999 6:00 PM
> To: 	Denis Pinkas
> Cc: 	CAT-IETF WG
> Subject: 	Re: GSS-API-Easy mechanism
> 
> 	I note that the encryption algorithm is not specified in the
> current draft.  Obviously this will need to be rectified in the long
> run.  This brings up the interesting question of which crypto algorithm
> to use.  The problem is that right now, there isn't any universally
> liked choices.  DES is too weak, triple-DES is too slow.  A number of
> other liked algorithms have Intellectual Property entaglements of one
> kind or another.  (RC4, IDEA, etc.)  When the AES process finishes in a
> year or so, I'm sure we'll be in a better position.  Until then, though,
> what do we do?  (I know, use the newly released Skipjack algorithm!  :-)
> 
One possibility is RFC 2144.  The CAST-128 cipher has no Intellectual
Property entanglements of any kind.

[I have been tied up with a number of things recently and so have not had a
chance to read Denis' draft.  I therefore have no opinion on the specific
OWF-encryption scheme which it proposes.  In general, though, Ted's point is
perfectly valid:  the properties of a OWF-based scheme for the purposes of
encryption are often not well understood.  Such a choice can be risky.]

Carlisle.