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

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