Document: draft-ietf-karp-crypto-key-table-07
Reviewer: David L. Black
Review Date: April 25, 2013
IETF LC End Date: April 29, 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, but the draft is
short on precision in specifying a number of the fields for the database,
and the IANA registries; most of the open issues are requests for the
level of precision needed for interoperability and reuse of database
implementation across different protocol implementations.

Major issues: 

(Section 2)

[1] LocalKeyName and PeerKeyName are strings.  What character set?
If Unicode (e.g., UTF-8?), add text on Unicode considerations (e.g.,
normalization).  Finding a Unicode expert will help in getting this
done quickly.  I have similar concerns for other strings, and in
particular, IANA should be told what a "string" is for any registry
field that contains one.

[2] I'm not sure that I understand what a KDF really is from its high
level description in this draft.  At the least, I'm surprised that the
importance of non-invertibility of a KDF is not mentioned - beyond that,
a functional description of inputs and outputs would help, including
a strong recommendation to inject unpredictable nonce material.  This
could be handled by referencing material on what a KDF is that exists
elsewhere.

(Section 4)

[3] It's important that this section cover all the fields involved in
the database lookups in Section 3 whose format may be protocol-specific
(the Direction and various time fields aren't).  Protocol should be
covered by the IANA registry, peers and key names are covered here,
but interface appears to be missing - item (9) covers presence vs.
absence of interface information, but not its format.

--- Lots of issues with the IANA Considerations (Section 8)

(Section 8.1.1)

[5] No field format information for the fields in a registry entry.
IANA should be told what formats to expect/use.

[6] "Protocol Specific Values" is not the same as "ProtocolSpecificInfo"
in section 2; the same name should be used, but whitespace differences
are ok.

[7] Should some sort of formats for Peers and Interfaces be included in
registering a Protocol?  If not, the lookups in section 3 may be
implementation-dependent (strings that work w/one implementation may
not work w/other implementations of the same protocol).  The specification
reference may suffice based on the requirements in section 4
for what has to be in each referenced specification.

(Sections 8.2 and 8.3)

[8] No registry entry content descriptions.  Need to supply information
on what to register and the formats of the elements of a registry entry.

[9] I suggest Expert Review for these 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.

[B] (Section 2) Where is key size recorded?  Is that an implicit attribute
of Key?

[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:

I suggest dividing section 3 into
- 3.1 Outgoing Traffic
- 3.2 Incoming Traffic

idnits 2.12.16 found a truly trivial nit -
  == Line 76 has weird spacing: '...strains  where...'

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black at emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------