Subject: RE: GSSAPI/AES draft

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 20 Aug 2003 03:53:24 -0700

>> Martin Rex wrote:
>> > For their NTLM SSPI-mechanism Microsoft made two stupid mistakes
>> > which cause severe usability problems: (1) they use a single
continuous
>> > keystream for all messages so that processing out of order
>> > is impossible and (2) they use the same keystream for both
>> > directions making the security context synchronous half-duplex...

>> That's not my reading of draft-brezak-win2k-krb-rc4-hmac-04.txt.

Nicolas Williams wrote:
>> In any case, the GSS-API does not support what you say MS did.  The
>> problem is that key setup can be expensive for some stream ciphers,
thus
>> encouraging one to minimize key setups; one solution might be to
define
>> a cheap, but secure, cipher state derivation function (as opposed to
key
>> derivation function) so that key setup can be done once and cipher
state
>> 
>> cna be derived at low cost for each encryption operation).

Martin, your point (2) is applicable only to NTLMv1/SSPI, which is
turned off on win2ksp3/winxp/ws2003 and can NOT be turned on at the API
level. For your point (1), most of applications are not capable of
handling oos messages, and if they do, SSPI does have a mode, as Nicolas
pointed earlier, that allows you to supply your own sequence numbers
hence process oos messages, so I do not know if it is accurate to
classify either (1) or (2) as "stupid mistakes". I see (1) as a
legitimate design decision to take advantage of the high performance
aspect of RC4, (2) as historical artifacts.

I tend to agree with Nicolas' cost analysis. I think
cipher-state-derivation function would be a great addition to kcrypto. 

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nicolas
Williams
Sent: Tuesday, August 19, 2003 4:38 PM
To: Martin Rex
Cc: JK Jaganathan; [email-masked]
Subject: Re: GSSAPI/AES draft

On Wed, Aug 20, 2003 at 12:17:10AM +0200, Martin Rex wrote:
> Nicolas Williams wrote:
> > The spec is quite clear that the oos/replay error codes are
> > supplementary to GSS_S_COMPLETE and that oos/replay detection errors
can
> > only be returned when the token could be verified/unwrapped
successfully
> > otherwise.
> 
> They are clear only because I requested them to be clarified this
> way very late in the GSS-API v2 standardization.  Very few
applications

Thank you.

> will probably conform to this, i.e. I don't expect MIT Kerberos to
> do the pairing of Sequencing-related errors with GSS_S_FAILURE
although
> the spec recommends this and MIT Kerberos makes these error fatal.

We define those errors as follows (from the C headers):

#define GSS_S_DUPLICATE_TOKEN (1 << (GSS_C_SUPPLEMENTARY_OFFSET + 1))
#define GSS_S_OLD_TOKEN (1 << (GSS_C_SUPPLEMENTARY_OFFSET + 2))
#define GSS_S_UNSEQ_TOKEN (1 << (GSS_C_SUPPLEMENTARY_OFFSET + 3))
#define GSS_S_GAP_TOKEN (1 << (GSS_C_SUPPLEMENTARY_OFFSET + 4))

and those are returned by gss_verify_mic()/gss_unwrap().

Note that there's no reference to GSS_S_FAILURE.

> > > The only gssapi mechanisms that can handle unsequenced messages
> > > are probably those that do *NOT* support sequence and replay
protection
> > > on protected messages.
> > 
> > Certainly NOT true.  The Kerberos mechanism easily handles contexts
with
> > and without either replay or out-of-sequence detection.
> 
> Sorry, but that is true.
> 
> If you request replay protection on a security context established
> with MIT Kerberos, you get enforced sequencing, and out-of-order
> processing of messages is then impossible.

I misunderstood what you meant by "unsequenced."  Yes, it's possible
that MIT's and/or Sun's implementations have problems with oos, but
those would not be the result of a bad spec (either rfc2743, rfc2744 or
rfc1964).

> > 
> > ONC RPC w/ RPCSEC_GSS is an example of a GSS-API application that
does
> > its own sequence and which never requests oos/replay detection from
the
> > GSS-API and which works just fine with the rfc1964 Kerberos V
GSS-API
> > mechanism.
> 
> In case that Kerberos offers security contexts without sequencing
> and without replay protection this might be possible -- and is almost
> what I claimed.  I have never tried doing that.  I hope that
> RPCSEC_GSS documents this special usage properly.

It certainly does.  See RFC2203.

Some applications do use replay detection just fine too (e.g., FTP).

Are there any applications that actually use oos?

> Does it also work with existing Kerberi that use RC4 encryption?

Good question.

> For their NTLM SSPI-mechanism Microsoft made two stupid mistakes
> which cause severe usability problems: (1) they use a single
continuous
> keystream for all messages so that processing out of order
> is impossible and (2) they use the same keystream for both
> directions making the security context synchronous half-duplex...

That's not my reading of draft-brezak-win2k-krb-rc4-hmac-04.txt.

In any case, the GSS-API does not support what you say MS did.  The
problem is that key setup can be expensive for some stream ciphers, thus
encouraging one to minimize key setups; one solution might be to define
a cheap, but secure, cipher state derivation function (as opposed to key
derivation function) so that key setup can be done once and cipher state
cna be derived at low cost for each encryption operation).

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 20 Aug 2003 06:28:06 -0700

> cipher-state-derivation function would be a great addition to kcrypto. 

I think you don't need any changes to kcrypto for that.  Basically
cipher state derivation fits into the key derivation and the encryption
functions.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 20 Aug 2003 08:45:53 -0700

> cipher state derivation fits into the key derivation and the encryption

To clarify, I think cipher state derivation fits into kcrypto through
lazy evaluation of key derivation.

That is, for an enctype with cipher state derivation, any kcrypto
function that creates keys could return:

{initial cipher state, [derivation params], [space for derived cipher state]}

and any kcrypto function that requires keys as input would perform the
cipher state derivation.

The cost of key setup is replaced with the cost of cipher state copies
and derivation.

Cheers,

Nico
--