Re: windows interop

[Jeffrey Hutzelman <jhutz@cmu.edu>]

--On Friday, December 14, 2007 01:38:39 PM +0100 Andy Polyakov 
<appro@fy.chalmers.se> wrote:

>> PA-ENCTYPE-INFO is not the only place where [non-existing in this
>> case] salt appears, it's exposed in PA-PW-SALT on wire
>
> Speaking of which. I've spotted following in 5.2.7.3 of RFC4120:
>
>     "... As
>     noted in section 3.1.3, a KDC MUST NOT send PA-PW-SALT when the
>     client's AS-REQ includes at least one "newer" etype."
>
> I can't see that 3.1.3 spells it this way though.

That's a bug.  IIRC, the reason for the requirement that KDC's not send 
PA-PW-SALT or PA-ETYPE-INFO when a new enctype is involved is that new 
enctypes require string-to-key parameters in addition to a salt, and there 
is no way to transmit them in those PA types -- that's why PA-ETYPE-INFO2 
was invented.  Unfortunately, I don't recall why this is required based on 
the enctypes requested by the client, rather than by the set for which the 
KDC intends to send data.


It's worth noting that RC4-HMAC is not defined not to have a salt; per 
RFC3961, all enctypes accept a salt as an input to their string-to-key 
operations.  What's interesting about RC4-HMAC is that the value of the 
salt does not affect the output of the string-to-key operation.  This 
abstaction is desirable, because it allows all the code that handles 
passwords and salts not to care what enctype is involved, other than the 
string-to-key operation itself.

If a client rejects RC4-HMAC when there is a non-empty salt, it breaks the 
abstraction, and then we have to start working around it.  That either 
means having the KDC handle this enctype specially when constructing AS-REP 
and KRB-ERROR/KDC_ERR_PREAUTH_REQUIRED, or having libkadm5 handle this 
enctype specially when storing salts into the KDB (note it can be done 
entirely on the server, but not entirely in kadmind, since other things may 
use the library to perform operations directly).


FWIW, I'm a little unclear on in which case you say W2K rejects RC4-HMAC. 
Does it do this when PA-PW-SALT and PA-ETYPE-INFO are absent, when the salt 
string is non-empty, or when the salt string differs from the default salt 
as defined in RFC4120 section 4 (see the fourth paragraph, at the bottom of 
page 48) ?


> For reference, presence
> of PA-PW-SALT in AS-REP does not seem to affect interop with Vista (which
> includes "newer" etype). A.