HELP!! invalid AS-REP from Linux running MIT Kerberos V5

[Marcus Watts]

"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