RE: Last Call: 'Guidance for AAA Key Management' to BCP (draft-housley-aaa-key-mgmt)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I agree that such a section on key management claims makes sense, but that should go in security considerations. I have some of the reservations that Sam has, but this is a necessary evil, IMO.

Lakshminath

At 03:08 PM 11/7/2006, Bernard Aboba wrote:
>

<snip>


Adding such a statement would at least make it clear to a reviewer that it
was the intent of the author to comply with the guidelines.  However, I
think that having a section on key management claims would make it easier
for a reviewer to examine a document and find the material relating to the guidelines.

For example, EAP method documents are required to include a security
claims section that is typically short since it typically just references
material already in the document or in external references.  Similarly a
Key Management Claims section might make it easier for a reviewer.  Such a
section might look like this:

"4.1.  Key Management Claims

   AAA Key Management requirements  are defined in [RFCXXXX].  This
   document claims to meet the following  requirements, as described
   below:

   Cryptographic Algorithm Independence:  Yes (See Sections 2.1, 2.3)
   Strong, fresh session keys: Yes (See Section 3.1, 3.4)
   Key scope: Yes (See Section 4.5)
   Replay protection: Yes (See Section 5.1)
   Authentication: Yes (See Section 2.6)
   Authorization: Yes (See Section 2.7)
   Key confidentiality: Yes (See Section 2.8)
   Confirmed ciphersuite selection: Partial (See Section 2.9)
   Key naming: Yes (See Section 6.1)
   Domino Effect: Yes (See Section 8.1)
   Key context binding: Yes (See Section 7.2)
   Confidentiality of Identity: No
   Authorization Restriction: Partial (See Section 6.2)"



> > While this document includes a lot of useful requirements, it does not
> > provide guidance on how document authors should demonstrate adherence to
> > the principles that are described.  For example, a AAA key management
> > document may not  include a section describing the assumptions and
> > requirements of the design, which can make it difficult for a reviewer
> > to determine whether or not the protocol fulfills its goals.  The
> > document describes a number of useful security properties, but there is
> > no request that document authors include sections in their
> > documents that correspond to these requirements.
> > As a result, my concern is that reviewers could be left with a large task
> > to determine whether a given document did or did not fulfill the
> > requirements described in this document.
> >
> > In order to make life easier for reviewers, it might be helpful for the
> > document to provide explicit guidance for draft authors.

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]