Subject: [karp] Gen-ART review of draft-ietf-karp-crypto-key-table-07

From: "Black, David" <[email-masked]>
Date: Thu, 25 Apr 2013 11:21:36 -0400

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
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Sam Hartman <[email-masked]>
Date: Thu, 25 Apr 2013 12:47:22 -0400

Here are some quick initial responses to your comments.

Thanks much for the review and I'll follow up with more detail in a
while.

>>>>> "Black," == Black, David <[email-masked]> writes:

    Black,> Major issues:

    Black,> (Section 2)

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

They are strings that can be compared using binary comparison.
I agree we need to state that in the draft.
Character set, to the extent it is specified will be specified by the
individual protocol.
In practice the protocol will say  that it's an integer represented as
an ASCII string.

We needed to add the entire complexity of making these fields be strings
    not integers because of some non-IETF protocols that use key names.

I'm reasonably confident I can sell Pete on the concept of a binary
    identifier for this field from an i18n standpoint.

But issues, of length, format, etc are all specified by the protocol
spec.

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

I'm open to text either proposed on the IETF list from one of the other
authors.
Some protocols have a KDF input some do not.
If they do, it will be drawn from a set of allowable valuable for that
protocol.

    Black,> (Section 4)

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

The interface is implementation-specific not protocol specific.  We
mandate that you must be able to tie things to interface. However the
format of an interface is quite specific to the routing platform in
questino.  I don't think there's a way that an IETF document can go into
useful detail on that.  SNMP and Netconf have models of how interfaces
are represented.  If we ever put together a Netconf schema for this
database, we'd specify the interface there.

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

    Black,> (Section 8.1.1)

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

Thanks, agreed.

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

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

When you register a protocol you need to point to a specification that
    gives details on this sort of thing.

    Black,> (Sections 8.2 and 8.3)

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

Thanks.

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

As an individual, I support FCFS, because I think getting expert
    approval for some of the uses that have been proposed for these
    registries will be challenging.

---

From: "Black, David" <[email-masked]>
Date: Thu, 25 Apr 2013 14:49:17 -0400

Thanks for the quick response - most of your message looks reasonable to me.

I have a few additional comments.

[1] Character set for key names, etc.

> I agree we need to state that in the draft.

That's certainly a reasonable goal, and there are plenty of examples of
protocols that do that.  OTOH, when the character set is Unicode, generating
strings for which that binary comparison for equality works as expected has
a number of subtleties when the strings are input by humans.  Pete Resnick
and yours truly are among the people familiar with the "dragons" that lurk
here (and the precis WG is grappling with).

>     identifier for this field from an i18n standpoint.

I have no problem with the field being a binary identifier, but I think
implementers should be put on notice that binary comparison of human input
Unicode strings doesn't work as expected unless some things are done to
make it work (this used to be known as string preparation).  A warning
to that effect, perhaps citing a reference for details on what can go awry,
accompanied by making the protocol spec responsible for getting this right
ought to suffice.

[3] Protocol responsibility to specify interface format

> We
> question.

Ok, I suggest explaining that as part of a statement that a protocol cannot
in general be expected to specify interface formats that apply across all
implementations due to implementation diversity.

[7] Additional format information in registry

>     gives details on this sort of thing.

That makes sense, and section 4's requirements on the specifications 
cover this area, but I thought I'd ask.

[9] Registry policy

>     registries will be challenging.

The two registries involved are for KDFs and cryptographic algorithm identifiers.

This feels like something that the security area ought to weigh in on, as it
looks like it includes the "vanity crypto" discussion tarpit ;-).  At a minimum,
I would think that there ought to be some means of prohibiting registration
of a crypto algorithm like ROT13 (http://en.wikipedia.org/wiki/ROT13).

Thanks,
--David

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]
> Sent: Thursday, April 25, 2013 12:47 PM
> To: Black, David
> Cc: Russ Housley; [email-masked]; [email-masked]; gen-
> [email-masked]; [email-masked]; [email-masked]; <[email-masked]>
> Subject: Re: Gen-ART review of draft-ietf-karp-crypto-key-table-07
>

---

From: Sam Hartman <[email-masked]>
Date: Thu, 25 Apr 2013 15:04:15 -0400

>>>>> "Black," == Black, David <[email-masked]> writes:

I've been there too. I've had a number of recent discussinos with Pete
about what the IESG is and is not happy with .
I'll write something up and I'm sure he and the rest of the IESG will
let us know if we got it wrong:-)

---

From: Ted Lemon <[email-masked]>
Date: Mon, 29 Apr 2013 14:37:43 +0000

On Apr 25, 2013, at 2:49 PM, "Black, David" <[email-masked]> wrote:
> make it work (this used to be known as string preparation).

+1.