Re: [kitten] FW: New Version Notification for draft-ietf-kitten-iakerb-00.txt

["Jim Schaad" <[e-mail]>]

We can easily define both numbers as extensions and say that servers must do
both, so that does not seem to be a big deal.

Is there any difference between the key usage of 41 and r2 that is
significant?

Jim


> -----Original Message-----
> From: Greg Hudson [mailto:[e-mail]]
> Sent: Thursday, April 11, 2013 1:40 PM
> To: Jim Schaad
> Cc: [e-mail]
> Subject: Re: [kitten] FW: New Version Notification for
draft-ietf-kitten-iakerb-
> 00.txt
> 
> Unfortunately, I have another issue to raise.
> 
> We implemented IAKERB for MIT krb5 1.9, but due to an oversight, we
> implemented draft-zhu-ws-kerb-03 instead of draft-ietf-krb-wg-iakerb-02.
>  Looking at the two drafts briefly, it appears that:
> 
> * Both use the same mech OID, the same IAKERB_PROXY token format, and
> the same error codes.  Both require an authenticator subkey in the AP-REQ.
> 
> * The two drafts define the "finished" extension slightly differently:
> 
>   - draft-zhu-ws-kerb-03 defines the data type as TBD and a key usage of
42.  In
> MIT krb5 1.9, we used an extension type of 1.
> 
>   - draft-ietf-krb-wg-iakerb-02 refers to draft-zhu-pku2u-09, which uses
an
> extension type of 2 and a key usage of 41.
> 
>   The two drafts use functionally identical ASN.1 sequences, checksum
> contents, and checksum keys.  They use different names for the data type,
> ASN.1 type name, and ASN.1 sequence field name, but those have no impact
> on the wire encoding.
> 
> Because of the differences in data type and key usage, the two drafts are
not
> interoperable.  Conceivably an acceptor could allow both versions of the
> finished extension, but an initiator would have to guess at what the other
end
> can accept.
> 
> The only other IAKERB implementation I'm aware of is in OSX, which appears
> to implement draft-ietf-krb-wg-iakerb-02.