>>>>> "David" == Black, David <david.black@xxxxxxx> writes:
David> Document: draft-ietf-karp-crypto-key-table-07 Reviewer: David
David> L. Black Review Date: April 25, 2013 IETF LC End Date: April
David> 29, 2013
David> (Section 2)
David> [1] LocalKeyName and PeerKeyName are strings. What character
David> set? If Unicode (e.g., UTF-8?), add text on Unicode
David> considerations (e.g., normalization). Finding a Unicode
David> expert will help in getting this done quickly. I have
David> similar concerns for other strings, and in particular, IANA
David> should be told what a "string" is for any registry field that
David> contains one.
Proposed fix;
The LocalKeyName field contains a string identifying the
key. It can be used to retrieve the key in the local database when
received in a packet. As discussed in Section 4, the protocol
defines the form of this field. For example, many routing protocols
restrict the format of their key names to integers that can be
represented in 16 or 32 bits. Typically this field does not contain
data in human character sets requiring internationalization.
If there ever are any Protocols with key names requiring
internationalization, those specifications MUST address
issues of canonicalization and normalization so that key names can be
compared using binary comparison.
David> [2] I'm not sure that I understand what a KDF really is from
David> its high level description in this draft. At the least, I'm
David> surprised that the importance of non-invertibility of a KDF
David> is not mentioned - beyond that, a functional description of
David> inputs and outputs would help, including a strong
David> recommendation to inject unpredictable nonce material. This
David> could be handled by referencing material on what a KDF is
David> that exists elsewhere.
The KDF field indicates the key derivation function which is used to
generate short-lived keys from the long-lived value in the Key field.
When the long-lived value in the Key field is intended for direct use,
the KDF field is set to "none". A key derivation function is a
one-way function that provides cryptographic separation of key
material. The KDF MAY use inputs from the row in the key table and
the packet being sent or received but MUST NOT depend on other
configuration state.
David> (Section 4)
David> [3] It's important that this section cover all the fields
David> involved in the database lookups in Section 3 whose format
David> may be protocol-specific (the Direction and various time
David> fields aren't). Protocol should be covered by the IANA
David> registry, peers and key names are covered here, but interface
David> appears to be missing - item (9) covers presence vs. absence
David> of interface information, but not its format.
The form of the interfaces field is not protocol-specific but instead
is shared among all protocols on an implementation. If a protocol
needs to distinguish instances running over the same interface, this
is included in the specification of peers. Generally it is desirable
to define the specification of peers so that an operator can use the
interfaces field to refer to all instances of a protocol on a link
without having to specify both generic interfaces information and
protocol-specific peer information.
David> --- Lots of issues with the IANA Considerations (Section 8)
I could really use some help from one of the other authors resolving the
IANA issues.
I've made the trivial fix of getting info vs values consistent.
David> [7] Should some sort of formats for Peers and Interfaces be
David> included in registering a Protocol? If not, the lookups in
David> section 3 may be implementation-dependent (strings that work
David> w/one implementation may not work w/other implementations of
David> the same protocol). The specification reference may suffice
David> based on the requirements in section 4 for what has to be in
David> each referenced specification.
I think section 4 should handle this.
We could add a bit of text reminding people that the specification needs
to address the issues brought up in section 4.
David> [9] I suggest Expert Review for these registries, not just
David> First Come First Served, so that someone with a security
David> "clue" can check that the proposed registrations are
David> reasonable.
I don't think I've seen support for this on the WG list.
David> Minor issues:
I don't think it does even conceptually.
It's much closer to the SPD.
However there are no plans I'm aware of to use this to configure IPsec
and I think several of us might push back against that.
David> [B] (Section 2) Where is key size recorded? Is that an
David> implicit attribute of Key?
yes.
David> [C] (Section 3) Where does key selection occur? I would
David> suggest that the database return all possible keys and let
David> the protocol figure out what to use. This is particularly
David> important for inbound traffic for obvious reasons.
No, the hope is that the key selection can be shared among protocols;
that's one of the main things that you get out of something like this.
The intent is that the protocol passes the things described in section 3
into the key table which pops out the right row.
We think this is solid for received packets; if you think we've missed
something please let us know: much easier to fix now!