Subject: [abfab] token encoding

From: Sam Hartman <[email-masked]>
Date: Thu, 07 Jul 2011 15:01:17 -0400

As discussed we're looking at having a MIC token in the final message
that indicates the checksum of everything in the last token.

It's format currently is

* DER encoding of the mechanism OID
* 2 byte outer token type

Then for each inner token besides the MIC token:
* 4 byte type
*  value of the token

In particular, the length of the subtokens are not included.

I think we should either include the lengths in the MIC or have a
convincing argument why you can't move bytes around between one subtoken
and other by attacking the lengths. 

I think this is safe; I'd appreciate though if someone else would
explain why they think it's safe and see if that matches up with my
understanding.  Alternatively, say that you want the length included.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 08 Jul 2011 09:53:10 -0400

>>>>> "Sam" == Sam Hartman <[email-masked]> writes:

    Sam> As discussed we're looking at having a MIC token in the final message
    Sam> that indicates the checksum of everything in the last token.

    Sam> It's format currently is

    Sam> * DER encoding of the mechanism OID
    Sam> * 2 byte outer token type

    Sam> Then for each inner token besides the MIC token:
    Sam> * 4 byte type
    Sam> *  value of the token

    Sam> In particular, the length of the subtokens are not included.

    Sam> I think we should either include the lengths in the MIC or have a
    Sam> convincing argument why you can't move bytes around between one subtoken
    Sam> and other by attacking the lengths. 

No, this encoding is not safe.  As far as I can tell you can simply
increase the length of one subtoken to cover other subtokens. For
example you could cause a vendor ID to eat some subtoken you didn't like
as an attacker.  Other attacks also may be possible.

However I think we need to include the length.  I'll write the spec
accordingly and will update the code.