[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: windows interop
--On Friday, December 14, 2007 01:38:39 PM +0100 Andy Polyakov
>> 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 18.104.22.168 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.