Subject: RE: looking for feedback on crypto draft: cipher state chaining

From: [email-masked]
Date: Wed, 12 Jun 2002 09:39:20 -0400

See RFC2712.

--  

> -----Original Message-----
> From: Derek Atkins [mailto:[email-masked]]
> Sent: Tuesday, June 11, 2002 5:52 PM
> To: Williams, Nicolas
> Cc: Ken Hornstein; [email-masked]
> Subject: Re: looking for feedback on crypto draft: cipher 
> state chaining
> 
> 
> "Nicolas Williams" <[email-masked]> writes:
> 
> > Bad example. Kerberos-TLS doesn't use AP-REQ/REP messages. 
> If that gets
> > through...
> 
> Ok, if it doesn't use AP-REQ/REP, what DOES it use?
> 
> -derek
> -- 
>        Derek Atkins
>        Computer and Internet Security Consultant
>        [email-masked]             www.ihtfp.com
> 

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

---

From: Martin Rex <[email-masked]>
Date: Fri, 14 Jun 2002 19:12:10 +0200 (MET DST)

Sam Hartman wrote:
> 
> I think we fundamentally disagree on the advisability of defining
> profiles for GSSAPI mechanisms.

I meant that an application protocol that is designed/extended
to be used with GSS-API definitely needs to specify which features
of GSS-API are required for the operation.  There's so much optional
in GSS-API that this is a must.

An example: the bare minimum service for GSS-API is unidirectional
authentication.  A simplistic mechanism need not to provide any
message protection services at all, and in fact, Microsoft's
NTLM (v1) mechanism is just one example for such a mechanism
which is already deployed on millions of machines out there.

I don't know whether the FTP security extensions support such
a mechanism (and if it does whether it describes how to deal
with it exactly, because the message protection calls will
probably always return errors).

> 
> I think this disagreement might be of great interest to the IETF
> security community when some of us involved in Kerberos revisions turn
> our attention to the Kerberos GSSAPI mechanism spec and to the GSSAPI
> framework after finishing revisions, but I see no advantage to trying
> to resolve these disagreements at the present time.  I recognize that
> you have a valid model for using GSSAPI and that you have significant
> implementation experience with that model.  However it is not the only
> way of thinking about things and there is also implementation
> experience with SSH, SASL (including LDAP and IMAP) and FTP with the
> use of GSSAPI.

I have read very few of the documents where application protocols
deal with GSS-API, but each one I read had some problems up to
severe design flaws.

Take Microsoft's proposal to use GSS-API based authentication for
HTTP-Requests the way they have implemented it in MSIE and IIS.
That's a really big mess.  (I commented on this before on this
list).  This proposal (I think it actually describes the existing
implementation) makes use of the complex SPNEGO protocol, *but*
it clearly violates SPNEGO in several aspects -- it requires an
optimistic context token to be included in the initial token
and it defines that if the optimistic token is not understood
the whole request fails -- i.e. there is no negotiation.

It also puts restrictions on the underlying GSS-API mechanism
in that it may use at most 2-way authentication.  How this
thing deals with the 3-way authencation of NTLM is still
unclear to me, as well as whether and how there's any kind of
context caching for successive requests (it's been a while
that I've read the initial document...).

-Martin