Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-kitten-cammac-00

From: Meral Shirazipour <[email-masked]>
Date: Sat, 6 Dec 2014 02:27:48 +0000

Hi Tom,
  Thank you for considering the comments. Please see inline.

Best Regards,
Meral

> -----Original Message-----
> From: Tom Yu [mailto:[email-masked]]
> Sent: Friday, December 05, 2014 6:02 PM
> To: Meral Shirazipour
> Cc: [email-masked]; [email-masked]
> Subject: Re: Gen-ART Last Call review of draft-ietf-kitten-cammac-00
>
> Thank you for your review.  I have written some responses below.
>
> Meral Shirazipour <[email-masked]> writes:
>
> > Nits/editorial comments:
>
> > [Page 1], Abstract section, please remove the duplication of the word
> abstract (first word of first sentence).
>
> Thanks; fixed in next revision.
>
> > [Page 1], Abstract, suggestion: the actual motivation should be briefly
> mentioned in the abstract. (e.g. that AD-KDC-ISSUED is not sufficient in cases
> where ...).
>
> I think the motivation is too complicated to concisely summarize in the
> abstract.  We could mention that AD-KDC-ISSUED has known shortcomings
> that will be detailed in the document, if that helps.

I think that would help.

>
> > [Page 3], "The svc-verifier element of the CAMMAC", is svc newly introduced
> in this draft? If so it would be clearer to mention it, e.g. "The new svc-verifier
> element of the CAMMAC"
>
> That paragraph indicates that the svc-verifier element of CAMMAC  takes the
> same role as the ad-checksum element of AD-KDC-ISSUED.  I think it doesn't
> qualify as new in this context.  Please let me know if there is alternative
> wording that would make this more clear.

In that case I would leave as is. Thank you for the clarification.

>
> > [Page 3], same sentence as above, should it be "AD-CAMMAC" instead of
> "CAMMAC" ?
>
> I think of CAMMAC as the abstract concept behind this authorization data,
> and of AD-CAMMAC as the ASN.1 type.  If this usage is confusing, we could
> change to use AD-CAMMAC more consistently throughout.

I think it is best to just use AD-CAMMAC then, or repeat the above explanation in the draft.

>
> > [Page 3], "svc-verifier", does svc acronym stand for something? (service and
> the Key Distribution Center ? ) Both svc and should be spelled out at first use.
>
> "svc" is a common abbreviation for "service", but we can expand it on the first
> use if that helps.  KDC is spelled out on its first use in the Introduction.

Yes it would be clearer to do that.

>
> > [Page 6], Section 5, if an Application server does not recognize the
> > AD-CAMMAC container and the latter was not enclosed in the
> > AD-IF-RELEVENT,
> >
> > should the Application server send an error or ignore ?
>
> RFC 4120 specifies that a server receiving unknown authorization data MUST
> fail the authentication process.  Do you think this needs repeating in this
> document?

Yes I think it would be good to mentioned it: "As stated in RFC4120, ..."

---

From: Tom Yu <[email-masked]>
Date: Fri, 05 Dec 2014 21:02:10 -0500

> [Page 1], Abstract section, please remove the duplication of the word abstract (first word of first sentence).

> [Page 1], Abstract, suggestion: the actual motivation should be briefly mentioned in the abstract. (e.g. that AD-KDC-ISSUED is not sufficient in cases where ...).

> [Page 3], "The svc-verifier element of the CAMMAC", is svc newly introduced in this draft? If so it would be clearer to mention it, e.g. "The new svc-verifier element of the CAMMAC"

That paragraph indicates that the svc-verifier element of CAMMAC  takes
the same role as the ad-checksum element of AD-KDC-ISSUED.  I think it
doesn't qualify as new in this context.  Please let me know if there is
alternative wording that would make this more clear.

> [Page 3], same sentence as above, should it be "AD-CAMMAC" instead of "CAMMAC" ?

I think of CAMMAC as the abstract concept behind this authorization
data, and of AD-CAMMAC as the ASN.1 type.  If this usage is confusing,
we could change to use AD-CAMMAC more consistently throughout.

> [Page 3], "svc-verifier", does svc acronym stand for something? (service and the Key Distribution Center ? ) Both svc and should be spelled out at first use.

"svc" is a common abbreviation for "service", but we can expand it on
the first use if that helps.  KDC is spelled out on its first use in the
Introduction.

> [Page 6], Section 5, if an Application server does not recognize the AD-CAMMAC container and the latter was not enclosed in the AD-IF-RELEVENT,
>

RFC 4120 specifies that a server receiving unknown authorization data
MUST fail the authentication process.  Do you think this needs repeating
in this document?

---

From: Simo Sorce <[email-masked]>
Date: Sat, 6 Dec 2014 12:29:54 -0500

On Sat, 6 Dec 2014 02:27:48 +0000
Meral Shirazipour <[email-masked]> wrote:

> > RFC 4120 specifies that a server receiving unknown authorization
> > data MUST fail the authentication process.  Do you think this needs
> > repeating in this document?  
> 

Hi, I have some reservations on repeating well established concepts
from another document. Should we ever amend the other document we risk
the 2 documents to become inconsistent.

It is also well-known what AD-IF-RELEVANT do, any implementer must
know it as it has to be properly dealt with in both clients and KDCs,
repeating shouldn't really be necessary.

Simo.

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

---

From: Meral Shirazipour <[email-masked]>
Date: Sat, 6 Dec 2014 20:57:04 +0000

Hi,
   I am ok either way, as gen-art reviewer it was not clear to me that the server  MUST fail the authentication process.

Best Regards,
Meral

> From: Simo Sorce [mailto:[email-masked]]
> Sent: Saturday, December 06, 2014 9:30 AM
> To: Meral Shirazipour
> Cc: Tom Yu; [email-masked]; [email-masked]
> Hi, I have some reservations on repeating well established concepts from
> another document. Should we ever amend the other document we risk the 2
> documents to become inconsistent.
> 
> It is also well-known what AD-IF-RELEVANT do, any implementer must know it
> as it has to be properly dealt with in both clients and KDCs, repeating
> shouldn't really be necessary.
> 
> Simo.
> 
> --