Issue in generating Authenticator Data in AP_REQ

[Sankar Das]

Hi Greg,
 
Many thanks for the clarification. I think I have now able to format the Authenticator Data properly as I am not getting the "ASN.1 identifier doesn't match expected value" error any more. But I am now getting KRB5KRB_AP_ERR_BAD_INTEGRITY error. My questions are:
 
1. I am not sending "checksum" field as it is optional in Authenticator data. Does KDC always expect it?
2. I am using OpenSSL encryption functions to generate the Authenticator. Is there any known issue in it? (Note: I am using enc-part of ticket received in AS_REP as encryption key and concatenation of principal's realm and name as salt string).
 
Thanks again
Sankar
 


--- On Fri, 8/17/12, Greg Hudson <ghudson at MIT.EDU> wrote:


From: Greg Hudson <ghudson at MIT.EDU>
Subject: Re: Issue in generating Authenticator Data in AP_REQ
To: sankar_das at yahoo.com
Cc: krbdev at mit.edu
Date: Friday, August 17, 2012, 9:51 PM


On 08/17/2012 02:56 AM, Sankar Das wrote:
> [62][TotalLen][30][TotalLen-2][A0][03][02][01][VNO][A1][REALMLEN][REALM][A2][PRINCIPALNAMELEN][PRINCIPALNAME]
> [A4][04][MICROSEC][A5][12][KRBTIME]

I can see several problems here:

* Lengths above 127 (which is common for the outer tags of an
authenticator) must be encoded as 8n B1 ... Bn, where B1...Bn are the
minimum number of octets needed to represent the length in base 256.
Your notation suggests that you're always encoding the length in one byte.

* The fields of an Authenticator are explicitly tagged.  For instance,
crealm is an explicitly tagged GeneralSrtring, which is encoded as
[A1][len][1B][REALMLEN][REALM] (len being the length of
[1B][REALMLEN][REALM]).

* The cname field should be a PrincipalName which is a sequence; you
appear to be trying to encode the unparsed form, which is never used in
RFC 4120 protocol units.

* DER forbids encoding integers in more bytes than are needed to
represent it, so your four-byte encoding of the microseconds field isn't
correct.  Our decoder doesn't care about that, but other decoders might.

* ASN.1 GeneralizedTime values are 15 bytes raw, 17 with type tag.  I'm
not sure where your length of 18 comes from for the timestamp.

You will probably be better off using an ASN.1 implementation like asn1c
(or maybe liblber if asn1c is too much) than you will trying to encode
this stuff by hand.  There are a lot of pitfalls to hand-coding DER.

Here's a sample authenticator pulled out of a debugger and annotated:

62 81 8a (application 2 tag, length 138)
  30 81 87 (sequence, length 135)
    a0 03 (context 0 tag, length 3; authenticator-vno field)
      02 01 05 (integer, length 1, value 5)
    a1 0d (context 1 tag, length 13; crealm field)
      1b 0b (generalstring, length 11)
        4b 52 42 54 45 53 54 2e 43 4f 4d ("KRBTEST.COM")
    a2 11 (context 2 tag, length 17; cname field)
      30 0f (context 0 tag, length 15)
        a0 03 (context 0 tag, length 3)
          02 01 01 (integer, length 1, value 1)
        a1 08 (context 1 tag, length 8)
          30 06 (sequence, length 6)
            1b 04 (generalstring, length 4)
              75 73 65 72 ("user")
    a3 17 (context 3 tag, length 23; cksum field)
      30 15 (sequence, length 21)
        a0 03 02 01 10 (context 0 tag containing integer 16)
        a1 0e (context 1 tag, length 14)
          04 0c (octet string, length 12)
            03 77 aa 1f e6 9d 9b 4f b1 51 14 7e (checksum bytes)
    a4 05 (context 4 tag, length 5; cusec field)
      02 03 09 8b b6 (integer, length 3, value 625590)
    a5 11 (context 5 tag, length 17; ctime field)
     18 0f (generalizedtime, length 15)
       32 30 31 32 30 38 31 37 31 35 33 34 33 32 5a (time bytes)
    [more bytes for the subkey, but I'll stop here]