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

From: "Black, David" <[email-masked]>
Date: Fri, 9 Aug 2013 10:47:05 -0400

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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 14 Aug 2013 03:06:45 +0800

Thank you for your review, David. The Gen-ART reviews are important feedback for me to understand where I should look more closely. 

In this case your review caused me to read the draft in detail, and I now have similar question as you did. I have raised a Discuss in my IESG ballot so that we can talk about those issues with the authors. In particular, it would be useful to discuss whether FCFS or some other assignment policy is most appropriate for the algorithm ID and KDF registries. I too thought Expert Review would have been a more natural fit. But I do not mind another policy, as long as we have a good reason for picking it. Secondly, I too was wondering what the relationship of this database is to the PAD.

Jari

---

From: Sam Hartman <[email-masked]>
Date: Wed, 14 Aug 2013 15:31:50 -0400

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

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

It doesn't.
not even a little bit.
It's not IPsec; it's not about what key management peers to interact
with.

It's conceptually similar to the Security Association Database (SAD).
In a discussion with Jari I agreed to propose text for a paragraph
describing how this interacts with IPsec.

If this conceptual database is used to manage to keys for a security
    protocol that uses IPsec [RFC4301] security services, then  the
    interactions between this conceptual database and the IPsec
    databases needs to be described by the protocol specification.
    Typically such a protocol would insert entries into the Security
    Association Database (SAD) when rows are inserted into the key table
    and remove SAD entries when key table rows are removed.  The
    protocol specification needs to describe how the SAD entries are
    constructed along with any other IPsec database entries that are
    needed, including a description of how these entries are ordered
    along with other IPsec database entries.  The question of whether it
    is desirable to use this conceptual database to manage protocols
    that use IPsec security services is open and has not been evaluated.

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

I think we've discussed key selection in the WG and come to a different
conclusion.  The key table selects the key.  We expect peer, key ID,
protocol and interface to identify a unique key for an inbound packet.

So, I think the concern you raise is not a problem.
While there was not a specific thread discussing key selection or this
issue, there were multiple reviewers who provided comments on key
selection over the development of the document, and making a major
change at this point without a technical problem seems undesirable.
If I'm missing something and the inbound packet issue is a problem then
we need to discuss it.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 14 Aug 2013 15:19:06 -0400

David, as we mentioned in the IESG thread, we seem to have dropped the
response to your comments about IANA actions.

WG:
>From the genart review:

Stephen has filed a related DISCUSS position.  He's confused why we need
a registry for  KDFs or algorithms.
He argues that the protocols should already have such a registry.  He
argues that it would be non-sensical to register a value in this
registry but not the protocol registry.

In a somewhat related discussion, multiple people have asked what the
scope of this document is.  Are we defining something for routing
protocols?  Any security protocol in the world?  Something in-between?

IU'm going to make two responses:

1)
I think FCFS is not harmful for these registries.

David's main concern is that bad security will get registered.

I'll point out that these registries are not about what security you can
use with a routing protocol, but about what security you can configure
from a management standpoint.
Registering rot13 or similarly questionable security here wouldn't mean
I could use it with a routing protocol, only that I could ask a system
to do so.  If ROT13 was not actually in the security-specific registries
for the protocols in question there'd be no way to send a
rot13-transformed message.

I think people wanting to use bad security in routing protocols will
focus on specifying how to use the security for the protocols, and
that's the appropriate place to do any gateway review.
Yeah, I guess with FCFS it's possible someone could register here and
then later realize they cannot get their md4 security approved in the
actual protocol registry document.

That might be confusing but doesn't seem very harmful.

Also, some routing protocols are protected by cleartext passwords sent
over the network.  We want to be able to manage that, so we will be
registering plaintext password in these registries.
I don't think anyone will come up with anything worse than that.

Finally, I think a lot of us have begun to question the value in
security review for codepoint assignment.  Some security WGs care a lot;
some don't seem to care much at all.

2)  Why I prefer FCFS or at least would object strongly to expert
review.

If we're going to say we want expert review I want us to give  expert
instructions at least good enough that I believe I could answer the
question of what registrations to approve if I were appointed the
expert.

I don't think we could come to consensus on those instructions very
easily.
In particular, I think it would be challenging for us to describe what
security protocols the protocol registry applies to and which ones it
does not.

I'm totally fine publishing this document knowing it will be used for
routing protocols but not knowing what beyond routing protocols it will
be used for.
If we do that FCFS makes a lot of sense.

So, my recommendation is that we keep our current registration policy.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 15 Aug 2013 16:04:55 -0400

David,

I agree with Sam here. The key table is analogous to the SPD in 4301, 
but not
the PAD.

Another doc being developed in the KARP WG does have a "Routing 
Authentication Policy
Database" (RAPD) that incorporates aspects of the PAD from 4301, as well 
as some
SPD fields.

Steve

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 15 Aug 2013 23:06:18 +0000

>> The key table is analogous to the SPD in 4301, but not the PAD.

Close to SAD not SPD for some RPs as it have negotiation result including keys. 
But not definitely analogous to the PAD.

--
Uma C.

---

From: "Black, David" <[email-masked]>
Date: Fri, 16 Aug 2013 13:00:11 -0400

Sam,

Thanks for picking this up.  Unlike my other two concerns with this draft,
I think we have a longer discussion ahead of us on this one.

> David's main concern is that bad security will get registered.

I understand the response to be two-fold:

1) It doesn't matter; the controlling registry for crypto algorithm usage
is the protocol-specific registry, not the key table database registry.

2) The guidance for the Expert Reviewer will be very difficult to write.

I'm not convinced by either of these, sorry.

I'm concerned that the two-registry subtlety in 1) will be lost on
implementers, especially because (as mentioned in the IESG thread), this
key table database is likely to see use beyond routing protocols.  Among
other things, it's being proposed as a general mechanism for keying RSVP,
not just RSVP-TE (I'm one of the co-chairs of the tsvwg WG that's
responsible for RSVP).  That key table databases registry is also likely
to be a place that designers of new protocols look to figure out what to
use for security.

> I don't think anyone will come up with anything worse than that.

I read the first sentence in Section 2 of this draft as excluding
cleartext passwords:

   The database is characterized as a table, where each row represents
   a single long-lived symmetric cryptographic key.

If someone wants to argue that a cleartext password is a "long-lived
symmetric cryptographic key", I'll go break out the popcorn and watch
w/amusement :-).

Seriously, if the intention is to include cleartext passwords, then I
think some more rewriting is in order, and I would suggest checking
directly with the Security ADs before going there.

As for 2), the fact that it will be difficult (with which I agree)
doesn't imply that it isn't necessary or shouldn't be done.  IMHO, we
really should be setting a bar that says that this sort of IETF
imprimatur of approval of a crypto algorithm actually means something.

I appreciate that FCFS provides an easier path forward, however I'm
reminded by analogy of something I learned from my grad school
software engineering professor:

	I can make the code run arbitrarily fast ...
	...  if it doesn't have to be correct.

I'm rather uncomfortable with this use of process expediency as a
rationale for avoiding a technical concern.

This may ultimately be an issue that the IESG needs to sort out, as the
level of security for IETF protocols and concerns about "vanity crypto" 
extend well beyond the karp WG, but discussion ought to start here.

Thanks,
--David

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]
> Sent: Wednesday, August 14, 2013 3:19 PM
> To: Black, David
> Cc: [email-masked]; [email-masked]; Dacheng Zhang
> ([email-masked]); General Area Review Team ([email-masked]);
> [email-masked]; [email-masked]
> Subject: Re: [karp] IANA policy for draft-ietf-karp-crypto-key-table-08
> 
> 
>

---

From: "Black, David" <[email-masked]>
Date: Fri, 16 Aug 2013 12:31:20 -0400

Sam,

Thanks for taking another look at this.  I think we're in good shape on
the IPsec relationship concern, but I think key selection responsibility
could use some more attention.

[A] The new text on the IPsec relationship looks good - I'd suggest also
adding a sentence to state that keys for IPsec pre-shared-key authentication
are not appropriate for this key database.

[C] The key selection responsibility was not clear to me from the draft -
the intent/design stated in your message is fine (and having one key
be returned is simpler, and probably more robust than handing
multiple keys to different protocol implementations and hoping

> protocol and interface to identify a unique key for an inbound packet.

My confusion stems from section 3 starting out by stating that the
key database is consulted "to find the key to use on an outgoing message"
followed by several sentences that indicate that the consultation may
result in multiple keys.  That leads to a suggestion and a question.

Suggestion: 

Add a new paragraph at the start of Section 3 to make the functional
responsibility clear:

  Key selection is the responsibility of the key database functionality;
  in all cases, the protocol requests a key, and the database returns one
  key or an indication that there is no matching key.  When multiple keys
  match a protocol's request, the key database selects one as described
  further in this section.

Question:

What happens, when despite all the measures described in Section 3,
multiple keys match a protocol's request?  How does one ensure that the
key databases at both ends of the security association return the same
key?

Thanks,
--David

> From: Sam Hartman [mailto:[email-masked]]
> Sent: Wednesday, August 14, 2013 3:32 PM
> To: Black, David
> Subject: Re: [karp] Gen-ART review of draft-ietf-karp-crypto-key-table-08
>

---

From: Carter Bullard <[email-masked]>
Date: Fri, 16 Aug 2013 13:57:17 -0400

Hey David,
Having been down this path a number of times, I would like to
suggest that one shouldn't attempt to qualify any algorithm,
technique, method or approach that may be submitted to the
registration process.

By suggesting that the registry somehow contains only " good "
strategies, without any consideration regarding a specific
implementation, you're making a claim that is unsupportable.
Bad implementations of " good " strategies can be worst than
plaintext passwords … really.

Let the user decide what mechanisms they want to use, based
on their criteria.

Clear text passwords used over a triple AES encrypted channel
is not "by definition" a bad strategy.  Theoretically, it could
be abstracted as a two-factor system, which has its advantages,
regardless of the perceived " strength ".  Why not ??

Carter

On Aug 16, 2013, at 1:00 PM, "Black, David" <[email-masked]> wrote:

> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp
>