Jeff's response seems to cover most of the points in my review. I see
what is going on with the magic numbers, but I can't say that I
understand the motivation or justification for the failure to start
registries from RFC4120... but then I wasn't tracking this wg.
Couple of points in line...
Regards,
Elwyn
Sam Hartman wrote:
"Elwyn" == Elwyn Davies <[EMAIL PROTECTED]> writes:
Elwyn> Well, I fear I may be going to provoke another version,
Elwyn> because although it is IMO almost ready for PS, the IANA
Elwyn> considerations need some attention.
But as you will see below, not from this draft.
Elwyn> I am also unsure if
Elwyn> the key usage number that is cited in s3.2.3.2 is right
Elwyn> (see detailed comment below).
Elwyn> It would also be good to make Appendix C a little more up
Elwyn> to the minute if it is going to remain in place.
It's as up to the minute as it can be.
The release of Windows anticipated by appendix C is Vista.
Note that the primary editor is the lead Kerberos developer for Microsoft.
I thought this might be the case ;-)
The text in Appendix C is not going to survive the test of time very
well. Jeff's reply indicates that the comments apply to Windows XP at
least to some extent. I am not familiar with the Kerberos capabilities
of Windows in depth, but I understand that Windows XP professional
implements the KDC since it can function as a domain controller. Maybe
Appendix C could both mention XP and make it clear that it is talking
about the next *server* OS release after Windows 2003 or some other
appropriate form of words.
Elwyn> Issues: s3.2.3.2: Key usage magic number 6. This number is
Elwyn> presumably taken from the list in RFC4120 but I can't tally
Elwyn> the usage in this draft with the specification in RFC4120
>> 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed
>> with the TGS session key (Section 5.5.1)
Elwyn> I suspect that this is NOT the same usage as #6 in RFC4120
Elwyn> and rfc1510ter draft and it needs a new key usage number
Elwyn> allocated.
*sigh* I suspect that it's too late to change this in all the
implementations. I agree it should not be the same key usage number.
However since key usage 6 is currently only used with the session key,
there is not a security problem using 6 again with the reply key for
this checksum. I think several vendors have shipping/almost shipping
code that works this way. So in order to change things you'd need to
show an actual security problem. I'm confident no such problem
exists.
I'll confirm with the WG chair and authors and probably end up
preparing an rfc editor note to describe the issue and to confirm 6 is
intended.
I suspected that might be the case. It also needs to be noted in
rfc1510ter and the eventual registry As you say it shouldn't cause an
actual security problem.
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
