Dear all,   I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.   These comments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any other last call comments.     Summary: This document is written well except security section and it proposed a new Kerberos Authorization Data container to address deficiency of existing Authorization Data container AD-KDC-ISSUED. It is almost ready to be published.   Editorial Comments: 1. Abstract Remove “ abstract: ” from the first sentence in the abstract. 2. Section 1, first paragraph said: “ This document specifies a new Authorization Data container for Kerberos, called AD-CAMMAC (Container Authenticated by Multiple MACs), that supersedes AD-KDC-ISSUED. ” Where is the AD-KDC-ISSUED specified, here is the suggested change: s/AD-KDC-ISSUED/ Authorization Data Type AD-KDC-ISSUED specified in [RFC4120]   3. I note inconsistency in the terms throughout the document, e.g., AD-CAMMAC vs CAMMAC, is there any difference between AD-CAMMAC and CAMMAC, if not, please use the consistent term. 4. Verifier-MAC definition of section 4 said: “ The key usage for computing the MAC (Checksum) is 64.   ” s/key usage/key usage number 5.SVC-Verifier definition of section 4 said: “ This field MUST be present if the service principal of the ticket is not the local TGS, including when the ticket is a cross-realm TGT. ” TGT needs to be expanded. 6. Where are AD-IF-RELEVANT container and AD-SIGNEDPATH specified? I believe AD-IF-RELEVANT container is specified in RFC4120.but where AD-SIGNEDPATH is specified? Not clear.   7. Section 8 said: “ The KDC MUST NOT create a new CAMMAC from an existing one unless the existing CAMMAC has a valid kdc-verifier, with two exceptions. ” What are two exceptions?   8. Section 8 said: “ The KDC thus avoids recomputing all of the authorization data for the issued ticket; this operation might not always be possible when that data includes ephemeral information such as the strength or type of authentication method used to obtain the original ticket.   ” What are operations referred to? avoids recomputing all of the authorization data or recomputing all of the authorization data?   Technical comments:   1.This draft specifies a new authorization data container AD-CAMMAC which allows for multiple Message Authentication Codes (MACs) or signatures to authenticate the contained Authorization Data elements. It looks multiple MACs can be applied to authenticate the same Authorization data. However when reading the kdc-verifier definition, it said: “ In contrast to the other Verifier-MAC elements, the KDC computes the MAC in the kdc-verifier over the ASN.1 DER encoding of the EncTicketPart of the surrounding ticket, but where the AuthorizationData value in the EncTicketPart contains the AuthorizationData value contained in the CAMMAC instead of the AuthorizationData value that would otherwise be present in the ticket. ” It looks to me KDC-verifier and svc-verifier are computed based on different AuthorizationData value.   Also section 8, paragraph 4, first sentence said: “ The method for computing the kdc-verifier does not bind it to any authorization data within the ticket but outside of the CAMMAC. ” I think this sentence is quite misleading, since it can be interpreted into two different meanings: a.   The method for computing the kdc-verifier only bind it to authorization data contained in the CAMMAC. b. The method for computing the kdc-verifier only binds it to authorization data at the outside of CAMMAC. I think the answer is the former. please rephrase it. also what about the method for computing the svc-verifier? Does it computed based on the same authorization data contained in the CAMMAC as kdc-verifier?   2. Section 8 last paragraph first sentence first said: “ The kdc-verifier in CAMMAC does not bind the service principal name    to the CAMMAC contents, because the service principal name is not    part of the EncTicketPart. ” And then in the last sentence, last paragraph of section 8, it said: “ If an application    requires an authenticated binding between the service principal name    and the CAMMAC or ticket contents, the KDC MUST include in the CAMMAC    some authorization data element that names the service principal. ” It looks to me applications allow establish binding between service principal name and CAMMAC contents, I feel these two sentence are contradict between each other.   3. Section 8, paragraph 4 said: “ The method for computing the kdc-verifier does not bind it to any    authorization data within the ticket but outside of the CAMMAC.  At    least one (non-standard) authorization data type, AD-SIGNEDPATH,    attempts to bind to other authorization data in a ticket, and it is    very difficult for two such authorization data types to coexist.   ” Can AD-KDC-ISSUED coexist with AD-CAMMAC? Does AD-KDC-ISSUED bind it to authorization data in the ticket?   4. From what section 8 is written, it doesn ’ t looks to me section 8 are focusing on discussing security risk or implication, rather than it discusses a lot about how CAMMAC is used or processed, e.g., Extracting CAMMAC from ticket, creating new CAMMAC from old CAMMAC, modifying CAMMAC, insert CAMMAC into a ticket, which I think are more related to usage in section 5. I am wondering how CAMMAC is revalidated by the recipient? What security issue is implicated if KDC creates a new CAMMAC from the existing CAMMAC? How does reducing ticket size is related to security concern? What if I place a kdc-verifier in the new CAMMAC? I can not find a clear answer in the draft.   Thanks! -Qin