HELP!! invalid AS-REP from Linux running MIT Kerberos V5
Marcus Watts
mdw at umich.edu
Tue Jul 11 19:20:18 EDT 2006
"Khosrova, Eliza" <Eliza.Khosrova at cda.canon.com> writes:
> Subject: HELP!! invalid AS-REP from Linux running MIT Kerberos V5
> Date: Tue, 11 Jul 2006 13:32:44 -0700
> Message-ID: <02954887D466F24D9F3FC9F47466DEF0075DA258 at cdaexchange.sc.rd.canon.com>
> From: "Khosrova, Eliza" <Eliza.Khosrova at cda.canon.com>
> To: <kerberos at mit.edu>
>
> Hello,
>
> Please help us!
>
> We are having a problem when processing AS-REP received from our KDC in
> Linux environment.
>
> Our Linux Configuration
> ==================
> We are running a standard Fedora 5 distribution.
> The kernel version is:
> Linux version 2.6.17-1.2139_FC5
> (brewbuilder at hs20-bc2-4.build.redhat.com)
> We are running an MIT Kerberos V5 KDC, installed using the package:
> krb5-server - 1.4.3-4.1.i386.
>
> We have a Kerberos client application that runs under Windows. The
> client application sent a valid AS-REQ to our KDC in Linux.
> The KDC successfully processed it and sent back AS-REP to our client
> application. However, when our application successfully decrypts
> The 'enc-part' field of AS-REP, it is of type EncTGSRepPart (application
> 26) instead of being of type EncASRepPart (application 25)
> as described in section 5.4.2 of RFC 1510 http://rfc.net/rfc1510.html .
> It seems like the AS-REP from our Linux is not conforming
> to RFC.
>
> Our application currently has to work for both Windows and Linux and
> when receiving AS-REP from Windows, we are getting a
> correct application type (i.e. EncASRepPart). Could you please tell us
> if you have seen this problem and if so, how to resolve it?
>
> As a test, I changed our application to accept application 26 as valid
> one for AS-REP and was able to process AS-REP completely
> and extract TGT and the key. However, the way our application is
> written, it can't accept both so we need to see why our KDC in
> Linux is giving us the wrong type.
>
> Thank you in advance and hope to hear from someone out there very soon!
> Eliza
cool problem. I'll bet there's some interesting history there.
MIT kerberos source has these interesting comments:
src/lib/krb5/asn.1/krbasn1.h
/*
* Older versions of the Kerberos are always sending the
* enc_kdc_rep_part structure with an application tag of #26, instead
* of using the application tag of #25 (AS REP) or #26 (AS REP) as
* necessary. Worse yet, they will only accept a tag of #26, so we
* need to follow this for backwards compatibility. #defining
* KRB5_ENCKRB5KDCREPPART_COMPAT will preserve this wrong (but
* compatible) behavior.
*/
#define KRB5_ENCKRB5KDCREPPART_COMPAT
and
src/lib/krb5/asn.1/krb5_encode.c
#ifdef KRB5_ENCKRB5KDCREPPART_COMPAT
krb5_apptag(26);
#else
/* XXX WRONG!!! Should use 25 || 26, not the outer KDC_REP tags! */
if (rep->msg_type == KRB5_AS_REP) { krb5_apptag(ASN1_KRB_AS_REP); }
else if (rep->msg_type == KRB5_TGS_REP) { krb5_apptag(ASN1_KRB_TGS_REP); }
else return KRB5_BADMSGTYPE;
#endif
Looks like it's working as coded. All of this logic appears to have
been in MIT since at least kerberos "1.0" in, um, 1995 --presumably
the older clients mentioned in the comment ought not be there anymore
so KRB5_ENCKRB5KDCREPPART_COMPAT could be not defined.
Out of curiosity, why wouldn't you let your kerberos library there
do the equivalent of krb5_get_in_tkt or krb5_get_init_creds ?
If you're doing decode_krb5_as_rep or decode_krb5_enc_kdc_rep_part,
or checking enc_part2->msg_type, that seems wrong...
-Marcus Watts
More information about the Kerberos
mailing list