RE: making progress

>From: 	david.brownell@Eng.Sun.COM[SMTP:david.brownell@Eng.Sun.COM]
>
>> Our current shared key proposal does not create "islands of
>> interoperation"; it specifies a single shared-key-based client
>> authentication mechanism.
>
>Well, I don't think you can have it both ways.
>
>Earlier, MS said that it was mechanism-neutral in response to
>criticism that it's not clear what character set or language to
>use for the "display_string" and "challenge" values.

I believe that what I said is that the content of the "display_string"
value is left to the discretion of the next-higher layer.  In our
current proposal, the authentication mechanism is otherwise completely
standardized.

>
>Now, I hear that it is in fact a single new mechanism (as I'd assumed
>originally).  And one which evidently does not support the primary
>shared-key standard in use on the Internet, Kerberos.  In which case
>it appears that the internationalization issues are real.


I think I might be able to resolve some of the confusion here.  An
earlier proposal of ours included a "private" authentication method in
addition to the "standard" one.  This "private" method was intended to
allow explicitly for non-standard authentication response formats.  In
response to criticism from several quarters, and after reconsidering the
issue ourselves, we removed this feature.  Our proposal is now for one
single interoperable shared-key authentication mechanism.  

As for Kerberos, it is not simply a shared-key authentication mechanism;
rather, it is an entire distributed security protocol, including key
management, authentication and key exchange.  I see no way to "support"
it in a completely incompatible context like TLS as it is currently
envisioned.  If you have ideas on that score, I'd be interested to hear
them; otherwise, our assumption is that Kerberos users would migrate to
TLS, allowing them to keep their infrastructure (in particular, their
password databases and overall authentication server/KDC-based
architecture) while replacing the low-level machinery that provides the
security functionality.

>
>I expect you can understand this inconsistency doesn't cause your
>proposal to come across very favorably.  I was quite serious when
>I said that the proposal wasn't well enough defined.  That's very
>distinct from the issue of whether it's a good thing to support a
>shared key framework, or the issue of whether you're confusing things
>by positioning this as "shared key support", which is an rather
>general notion that is relatively well understood.

We are certainly not "positioning this as 'shared key support'".
Rather, we are proposing a specific mechanism for using a shared key for
client authentication, within the framework of an SSL-style
server-authenticated public-key key exchange as provided by TLS.

>
>It'd be a lot better if you just sent a bunch of uncharacterized
>opaque data with some kind of identifier for the shared key system
>in use ... that kind of approach would stand a chance of supporting
>the non-Microsoft shared-key systems out there; you'd win friends if
>you suggested ways to use the tokens GSS-API produces.
>

I assume you mean Kerberos tickets; I don't see why TLS (whether with
shared-key or public-key client authentication) can't simply be
implemented under GSS-API.  But the parallel co-existence of Kerberos
with TLS raises so many questions (Which key exchange is used?  Which
server authentication?) that I'd rather understand what, exactly, you
have in mind before responding.


				Daniel Simon
				Cryptographer, Microsoft Corp.
				(dansimon@microsoft.com)

Received on Monday, 28 October 1996 13:17:17 UTC