Subject: [kitten] I-D Action: draft-ietf-krb-wg-cammac-09.txt

From: [email-masked]
Date: Fri, 05 Sep 2014 12:57:55 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF.

        Title           : Kerberos Authorization Data Container Authenticated by Multiple MACs
        Authors         : Simo Sorce
                          Tom Yu
                          Thomas Hardjono
	Filename        : draft-ietf-krb-wg-cammac-09.txt
	Pages           : 9
	Date            : 2014-09-05

Abstract:
   Abstract: This document specifies a Kerberos Authorization Data
   container that supersedes AD-KDC-ISSUED.  It allows for multiple
   Message Authentication Codes (MACs) or signatures to authenticate the
   contained Authorization Data elements.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-krb-wg-cammac/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-krb-wg-cammac-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-krb-wg-cammac-09

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Tom Yu <[email-masked]>
Date: Fri, 05 Sep 2014 16:34:15 -0400

This revision makes some editorial wording changes in responses to
feedback.

At Greg's suggestion, kdc-verifier is now optional, and I have
documented the relevant security considerations for this.

I've also specified the non-criticality semantics.

I appear to have forgotten to add text documenting the service principal
binding issue.  Does someone want to suggest wording?

I believe these changes all have at least rough WG consensus behind
them, but the chairs are welcome to clarify whether they agree that
there is consensus.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 8 Sep 2014 12:29:11 -0400 (EDT)

> This revision makes some editorial wording changes in responses to

Thanks for the updates.

Aside from the extra "be" (in "be use") that Simo pointed out on IRC, I am
still not sure that I understand the last paragraph of the security
considerations.  That is, I don't see how using the S4U2Proxy extension
and having policy disallow the use of S4U2Proxy would result in similar
security properties.

-Ben

---

From: Greg Hudson <[email-masked]>
Date: Mon, 08 Sep 2014 12:58:46 -0400

> and having policy disallow the use of S4U2Proxy would result in similar

I tihnk the extra "be" is supposed to be "not" or "never".

I suggest changing:

    The KDC MAY create a new CAMMAC from an existing CAMMAC	
    lacking a kdc-verifier if it is inserting the new CAMMAC into a	
    service ticket for the same service principal as the ticket that	
    contained the existing CAMMAC, and if all of the realm's KDCs are	
    configured to reject S4U2Proxy requests made by that service	
    principal.

to instead say, "... as the ticket that contained the existing CAMMAC,
but MUST NOT place a kdc-verifier in the new CAMMAC."  This is simpler
to implement.  By not putting a kdc-verifier in the new CAMMAC, we don't
risk treating the new CAMMAC contents as definitively KDC-originated for
a subsequent S4U2Proxy request if the policy changes.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 8 Sep 2014 14:28:43 -0400 (EDT)

> I tihnk the extra "be" is supposed to be "not" or "never".

Yes, I think it makes more sense with that substitution.

> a subsequent S4U2Proxy request if the policy changes.

That seems reasonable to me.

-Ben