Subject: Re: SASL mechanism registration issue

From: "Jack De Winter" <[email-masked]>
Date: Tue, 05 Nov 1996 13:33:42 -0500

>I agree that the "X-" convention has caused numerous problems and
>uglyness.  I don't wish to see it continue.
>
>On the other hand, I think it is important to distinguish published
>non-proprietary authentication mechanisms from vendor specific proprietary
>or patented solutions.  While there hasn't been much experience in the
>area, I happen to find the new rules for media types attractive (minus the
>historical X- garbage).  Specificly have a "vnd." prefix with a trivial
>registration requirement, and reserve other names for protocols intended
>for wide deployment with a published specification.

At least is might curtail such things as the Microsoft Mail Client
trying to support an authentication type of 'twinkie'. ;-)

Two things in the base spec I would like to address though:

1) Is it possible for the encryption/authentication examples
to include relevant data for a non-existant user.  One of the
hard parts in implementing these is having a solid example to
test against.  For example, the SKEY example does not say if
it uses MD4/MD5 and does not provide information on what the
original password was.  Adding this would give a solid beginning
test for implementors.  Building a couple of examples would be
even better.

2) Is it possible to state explicitly whether or not to use MD4/MD5
for the SKEY implementation?  Or even have a SKEY-4 and SKEY-5 to
distinguish between the two?

regards,
Jack

---

From: Mike Macgirvin <[email-masked]>
Date: Tue, 5 Nov 1996 14:03:19 -0800 (PST)

> distinguish between the two?

Having a commercial product which uses S/Key, we've also noticed that this is a
deficiency. There is a secondary problem with S/Key in that the count needs to
be reset occasionally, and there is no standard protocol which addresses this.
I'd like to see both of these handled - hopefully within SASL. The S/Key RFC is
MD4 based, but there is no reason why we can't plan for the future. Putting MD5
capability in is the easy one; since we still run under the same framework.
Just declare a new type like SKEY+ or something which provides the algorithm as
an argument in the server prompt. Under IMAP, this could look like

	C: A001 AUTHENTICATE SKEY+
	S: + <count SP seed SP algorithm>64
	C: <six english words>64
	S: A001 OK

	S/Key initialize is a stranger beast. It actually needs to live in the
application protocol as a separate command unless we can shoe-horn it into
SASL. 

	C: A002 SKEYINIT [[count] [seed] [algorithm]]
	S: <count SP seed SP algorithm>64
	C: <six english words>64
	S: A002 OK

	This works as long as one provides the rule that SKEYINIT can only be
issued in the authenticated state. The algorithm is then used for all
subsequent S/Key sessions. Note that here we run into the problem of
negotiating which algorithms are supported on both ends; which speaks to a
broader problem of changing passwords remotely. 

	Before this list really got going I posted a message to the effect that
in both this (s/key) and SSL, we have needs which no longer qualify as "simple"
and which stretch SASL quite a bit. Can it be stretched, or do we have to live
with it? That's the $64M Q. 

	SASL was born around a simple challenge/response mechanism for
authentication, primarily to allow Kerberos and S/Key. SSL is a case where the
rules are reversed from Kerberos - one needs to negotiate _encryption_ which
may or may not _authenticate_ as a side result. This means that "AUTHENTICATE"
or "AUTH" would be overloaded. S/Key basically works but there is more we'd
like to see done with it to make it practical. We also have a problem of
servers "advertising" their local policy and mechanisms (although at least the
mechanisms are advertised in IMAP4rev1). 

	The case I'm thinking of is a server policy which says "we do not
accept authentication without a security layer; we support SSL or Kerberos5. If
you provide SSL security, you may authenticate with SSL client credentials,
LOGIN, SKEY, or CRAM." 

	But this brings a lot of complexity to an otherwise simple
challenge/response scheme. I'm prepared for flames which say this isn't the
proper place to address these issues. Problem is, no place else is any better.
If SASL can't live up to this challenge, it may not be general enough to extend
to protocol 'n' - which doesn't make it (SASL) a perfect solution for
extendable security. This may be OK and SASL may end up being to security what
POP is to IMAP - simple, but not powerful enough for the long haul. Do we need
a framework which fits this need? I say yes. 

Mike Macgirvin			<[email-masked]>
Postmaster General		Netscape Communications Corporation
Mail Server Engineering		http://netscape/people/max/

Any views expressed etc., etc.

---

From: Mike Macgirvin <[email-masked]>
Date: Tue, 5 Nov 1996 14:03:19 -0800 (PST)