[Gen-art] Gen-ART review of draft-ietf-karp-crypto-key-table-08

["Black, David" <[e-mail]>]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-karp-crypto-key-table-08
Reviewer: David L. Black
Review Date: August 9, 2013
IETF LC End Date: April 29, 2013
IETF Telechat Date: August 15, 2013

Summary:  This draft is on the right track, but has open issues
described in the review.

This draft describes a conceptual key database for use by protocols.
It's definitely useful and valuable work, as key management is often
an afterthought in protocol design, even when security functionality
is actively worked on in the design process.  The draft text is in
good shape and reads cleanly.

The draft authors have addressed most of the issues and concerns from
the GenART review of the -07 version of this draft, but three issues
remain.  I am particularly concerned with the first issue about whether
FCFS is appropriate for these security-related registries, and believe
that topic deserves IESG discussion.  The three issues are ([9], [A] and
[C] are the issue identifiers used on the original Gen-ART review of the
-07 version of this draft):

Major issue:

[9] I suggest Expert Review for the new IANA registries, not just 
First Come First Served, so that someone with a security "clue" can
check that the proposed registrations are reasonable.

Minor issues:

[A] Overall - I would like to see a paragraph added on how this database
conceptually relates to the IPsec Peer Authorization Database (PAD) -
see RFC 4301, section 4.4.3.

[C] (Section 3) Where does key selection occur?  I would suggest that
the database return all possible keys and let the protocol figure out
what to use.  This is particularly important for inbound traffic for
obvious reasons.

Nits/editorial comments:

First paragraph in 8.1.2 should be at end of 8.1.1.

idnits 2.12.17 found two nits - the latter one (2119 reference/boilerplate)
needs attention:

  ** There are 2 instances of too long lines in the document, the longest one
     being 6 characters in excess of 72.

  ** The document seems to lack a both a reference to RFC 2119 and the
     recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
     keywords. 

     RFC 2119 keyword, line 194: '...tion of key material.  The KDF MAY use...'
     RFC 2119 keyword, line 196: '... or received but MUST NOT depend on ot...'

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------