[640] in Kerberos-V5-bugs
GSS-API OID confusion for Kerberos V5
daemon@ATHENA.MIT.EDU (Shawn Mamros)
Mon Aug 15 17:35:22 1994
Date: Mon, 15 Aug 94 17:38:42 EDT
To: krb5-bugs@MIT.EDU, Linn@cam.ov.com
Cc: mamros@ftp.com
From: mamros@ftp.com (Shawn Mamros)
Reply-To: mamros@ftp.com
I'm sending this message to both the krb5-bugs list at MIT and the
author of Internet Draft draft-ietf-cat-kerb5gss-01.txt, to point
out an apparent inconsistency between the MIT Kerberos V5 Beta 4
(patchlevel 2) implementation of GSS-API on top of Kerberos V5 and
the aformentioned document. My apologies if this issue has already
been brought up and resolved, or if I've overlooked something...
Quoting from section 2.1.1 of the Internet Draft:
2.1.1 Kerberos Principal Name Form
This name form shall be represented by the Object Identifier {iso(1)
member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
krb5(2) krb5_name(1)}. The recommended symbolic name for this type is
"GSS_KRB5_NT_PRINCIPAL_NAME".
Yet, when I look at the relevant source module (found in
./src/lib/gssapi/krb5/gssapi_krb5.c), I see the following comment:
* The OID of the krb5_name type is:
* iso(1) member-body(2) US(840) mit(113554) infosys(2) gssapi(1)
* krb5(2) krb5_name(1) = 1.2.840.113554.2.1.2.1
which is what the code seems to implement. Note that the numeric IDs
for "infosys" and "gssapi" are reversed. The same fields in the other
OIDs described are consistently reversed between those in the Internet
Draft and those in the code (.src/lib/gssapi/generic/gssapi_generic.c
is also impacted).
Is the specification correct and the code in error, or could it be the
other way around? Either way, I'd appreciate knowing which it is, or
if my observations are off.
Thanks,
-Shawn Mamros
E-mail to: mamros@ftp.com
