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

From: "Jim Schaad" <[email-masked]>
Date: Thu, 11 Apr 2013 02:20:05 -0700

This document is a match for the old krb-wg version of the document.

A set of updates and questions will be forthcoming.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, April 10, 2013 11:41 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: New Version Notification for draft-ietf-kitten-iakerb-00.txt
> 
> 
> A new version of I-D, draft-ietf-kitten-iakerb-00.txt has been successfully
> submitted by Jim Schaad and posted to the IETF repository.
> 
> Filename:	 draft-ietf-kitten-iakerb
> Revision:	 00
> Title:		 Initial and Pass Through Authentication Using Kerberos V5
> and the GSS- API (IAKERB)
> Creation date:	 2013-04-10
> Group:		 kitten
> Number of pages: 9
> URL:             http://www.ietf.org/internet-drafts/draft-ietf-kitten-iakerb-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-ietf-kitten-iakerb
> Htmlized:        http://tools.ietf.org/html/draft-ietf-kitten-iakerb-00
> 
> 
> Abstract:
>    This document defines extensions to the Kerberos protocol and the
>    GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to
>    exchange messages with the KDC using the GSS-API acceptor as the
>    proxy, by encapsulating the Kerberos messages inside GSS-API tokens.
>    With these extensions a client can obtain Kerberos tickets for
>    services where the KDC is not accessible to the client, but is
>    accessible to the application server.
> 
> 
> 
> 
> The IETF Secretariat

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 11 Apr 2013 11:55:34 -0700

I have an updated version of this document that corrects the references to
deal with published document.

There is one blocking issue on this document that needs to be dealt with.
In the next to last paragraph of section 3 there is a reference to [PKU2U]
which, if you following the missing reference, is
https://datatracker.ietf.org/doc/draft-zhu-pku2u/ This document is currently
expired and, per Sam, was never intended to be a krb-wg document.  We can
either try and revive this document as well or just copy the sections
dealing with  GSS_EXTS_FINISHED.  If we do the copy, then these sections
appear to be:

1.  The definition of it in section 6.3.   I need to get a second set of
eyes to determine which of the paragraphs need to be copied over.  My
current guess is:
	 The last sentence of the paragraph that start "The 'cksum' fields
of the"
	The ASN.1 blocks for GSS_EXTS_FINISHED and KRB-FINISHED
	The paragraph starting "The gss-mic field contains"
	I believe the last 3 paragraphs in the section are omitted.

2.  The paragraph dealing with GSS_EXTS_FINISHED in section 10 (IANA)

3.  Is an ASN.1 module needed or not?

Once this is finished then a new WG Last call is going to need to be done.

Jim

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Jim Schaad
> Sent: Thursday, April 11, 2013 2:20 AM
> To: [email-masked]
> Subject: [kitten] FW: New Version Notification for
draft-ietf-kitten-iakerb-
> 00.txt
> > A new version of I-D, draft-ietf-kitten-iakerb-00.txt has been
> > successfully submitted by Jim Schaad and posted to the IETF repository.
> >
> > URL:
http://www.ietf.org/internet-drafts/draft-ietf-kitten-iakerb-
> 00.txt
> > Status:
http://datatracker.ietf.org/doc/draft-ietf-kitten-iakerb
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: Greg Hudson <[email-masked]>
Date: Thu, 11 Apr 2013 16:39:42 -0400

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.

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 11 Apr 2013 14:25:39 -0700

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

> From: Greg Hudson [mailto:[email-masked]]
> Sent: Thursday, April 11, 2013 1:40 PM
> To: Jim Schaad
> Cc: [email-masked]
> Subject: Re: [kitten] FW: New Version Notification for
>   - 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.
> 
an
> extension type of 2 and a key usage of 41.
> 
> 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.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 15 Apr 2013 15:57:10 -0700

Larry

Do we know if Msft has also implemented this and if so which did they use?

Jim

42.  In
an
not
end

---

From: Luke Howard <[email-masked]>
Date: Tue, 16 Apr 2013 09:29:27 -0400

I don't think MS implemented it, last time I checked.

Greg -- I know you don't want to break stuff, but do you know if anyone has deployed MIT's IAKERB? Could we make the old initiator behaviour a config time option?

-- Luke

---

From: Greg Hudson <[email-masked]>
Date: Tue, 16 Apr 2013 11:39:32 -0400

> both, so that does not seem to be a big deal.

That's enough in the long term, and I can't think of anything which
would be helpful to initiators in the short term.  (Even if we could
find a way for acceptors to indicate whether they support
draft-zhu-ws-kerb or draft-ietf-krb-wg-iakerb or both, the only
acceptors who would implement it would be the ones are are agnostic anyway.)

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

The key usage is just a number, used as input for RFC 3961 key
derivation.  I didn't find any other differences between the checksums
in my reading of the two drafts; they both appeared to use the same keys
and contents.