[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
comments on the latest GSSAPI draft changes
Derrell, there are serious problems with the IDs in your latest rev. of the
draft.
In the prior version of the draft, the next payload for the GSS_API payload
was 129. In the latest, it is 128. Also, the auth id for GSS_API/Kerberos
in the previous version was 65001. In the current version, it is 65003, and
the generic GSS_API id is 65001.
In the presentation of the GSSAPI+Kerberos that I gave at the IETF, I gave
the numbers 129, 65001 as the numbers to use. These are the numbers in the
current version on NT5, and NT5 is shipping with these numbers.
Your change of these numbers will make it very difficult for other vendors
to implement the GSSAPI draft, and interop with NT5. I know of a few
vendors out there who want to do this. It will also make it very difficult
for later versions of NT to interop with NT5.
I see no security concerns, or any other valid reasons for changing these
IDs, and respectfully request that you put them back to their original
values.
Interoperability with GSSAPI will be tough enough since everyone building
this will need to build in backwards compatibility code anyway when we move
to the IANA assigned numbers. At least that backwards compatability is
possible. Given your current changes, backwards compatibility and general
interop is next to impossible.
I think it will be a major obstacle to the adoption of this draft if these
numbers stay as they are. Also, please push to get IANA assigned numbers
ASAP, so we never have to deal with the floating number problem in GSSAPI
again.
bs
Follow-Ups: