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@xxxxxxx Mobile: +1 (978) 394-7754 ----------------------------------------------------