Last Call Review of draft-ietf-kitten-cammac-00
review-ietf-kitten-cammac-00-opsdir-lc-wu-2014-12-04-00

Request Review of draft-ietf-kitten-cammac
Requested rev. no specific revision (document currently at 04)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2014-12-09
Requested 2014-11-28
Other Reviews Genart Last Call review of -00 by Meral Shirazipour (diff)
Genart Telechat review of -00 by Meral Shirazipour (diff)
Genart Last Call review of -04 by Meral Shirazipour
Review State Completed
Reviewer Qin Wu
Review review-ietf-kitten-cammac-00-opsdir-lc-wu-2014-12-04
Posted at http://www.ietf.org/mail-archive/web/ops-dir/current/msg00640.html
Reviewed rev. 00 (document currently at 04)
Review result Has Nits
Draft last updated 2014-12-04
Review completed: 2014-12-04

Review
review-ietf-kitten-cammac-00-opsdir-lc-wu-2014-12-04






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