Subject: [kitten] CAMMAC-05: Verifier-MAC etc

From: Zhanna Tsitkov <[email-masked]>
Date: Tue, 16 Jul 2013 20:30:06 +0000

Couple comments on CAMMAC rev5 draft.

1.  Verifier-MAC is defined as a sequence of an optional principal name and  required fields  kvno, enctype and a checksum.  It seems that in some cases providing both kvno and enctype might be redundant and even unnecessary.  (For example, in some cases enctype can be deduced from kvno, while svc-verifier may not need them at all.)  So, it might be a good idea to make either both these fields (kvno and enctype) "optional", or, at least, mark enctype as an  "optional" field.   

The following comments are mostly about text clarity:

2. In section 3 "Validation" the third paragraph starts with "The following information is needed:" and then lists "The KDC  MAC" , "The Service MAC" etc.  This text is followed by the statement "The KDC MAC is required to allow KDC to validate …"  The question that stays unanswered is what is  "The KDC  MAC" , "The Service MAC"?  What mac they are of? 

3. When giving details on AD-CAMMAC-BINDING (section 4.1) at the end of the paragraph one mentions S4U2proxy scenario.  It might be a good idea to move this text closer to the Introduction or, even, have a separate "Use Cases" section for potential use of AD-CAMMAC.

4. . In "Security Consideration" section the text "protected by the existing encryption methods on the ticket" implies that there are  multiple enc methods on one ticket.  Something simple like  "encryption method on the ticket" or similar would do a job.

Thanks,
Zhanna

---

From: Simo Sorce <[email-masked]>
Date: Tue, 23 Jul 2013 13:34:59 -0400

On Tue, 2013-07-16 at 20:30 +0000, Zhanna Tsitkov wrote:
> 1.  Verifier-MAC is defined as a sequence of an optional principal
> name and  required fields  kvno, enctype and a checksum.  It seems
> that in some cases providing both kvno and enctype might be redundant
> and even unnecessary.  (For example, in some cases enctype can be
> deduced from kvno, while svc-verifier may not need them at all.)  So,
> it might be a good idea to make either both these fields (kvno and
> enctype) "optional", or, at least, mark enctype as an  "optional"
> field.   

I was going to object having them optional but after some out of band
discussion I think it is fine to make enctype and kvno optional.

> 2. In section 3 "Validation" the third paragraph starts with "The
> following information is needed:" and then lists "The KDC  MAC" , "The
> Service MAC" etc.  This text is followed by the statement "The KDC MAC
> is required to allow KDC to validate …"  The question that stays
> unanswered is what is  "The KDC  MAC" , "The Service MAC"?  What mac
> they are of? 
> 
> 3. When giving details on AD-CAMMAC-BINDING (section 4.1) at the end
> of the paragraph one mentions S4U2proxy scenario.  It might be a good
> idea to move this text closer to the Introduction or, even, have a
> separate "Use Cases" section for potential use of AD-CAMMAC.
> 
> 4. . In "Security Consideration" section the text "protected by the
> existing encryption methods on the ticket" implies that there are
> multiple enc methods on one ticket.  Something simple like
> "encryption method on the ticket" or similar would do a job.

Thanks, these suggestions to clarify the text are welcome.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York