[karp] Review of karp documents

[Eric Rescorla <ekr at rtfm.com>]

$Id: draft-ietf-karp-threats-design-framework-combined-00-rev.txt 113
2010-03-21 01:19:14Z ekr $

I recently read these documents. A consolidated review is below.

OVERALL
- These documents contain an enormous amount of duplicated text.
  For instance, S 1.1 appears to be more or less identical between
  threats-reqs and framework. It would significantly help
  intelligibility to have this text appear in only one place
  and have references from other documents.

- A number of the technical statements about cryptography in these
  documents are at best dubious and at worst flat-out incorrect.
  In some cases, these errors are innocuous, but in others they
  lead to incorrect guidance.

- The terminology used in these documents is distinctly non-standard
  and should be aligned to standard communications terminology.

- There seems to be a basic a assumption throughout these documents
  that the right design is a decomposed system with separate
  traffic protection and key management pieces. IMO this has not
  served us particularly well in IPsec, so I'm not sure why we
  would want to repeat it. In particular, there are settings where
  an integrated comsec protocol such as (D)TLS or SSH would be
  attractive candidates, but the way these documents are written
  appears to rule them out of scope. Why?


DRAFT-IETF-KARP-THREATS-REQS:
1.1.
   PRF            Pseudorandom number function, or sometimes called
                  pseudorandom number generator (PRNG).  An algorithm
                  for generating a sequence of numbers that approximates
                  the properties of random numbers.  The sequence is not
                  truly random, in that it is completely determined by a
                  relatively small set of initial values that are passed
                  into the function.  An exmaple is SHA-256.

This is not what a PRF is. Here is the Wikipedia defn. which is reasonably
correct:

    In cryptography, a pseudorandom function family, abbreviated PRF,
    is a collection of efficiently-computable functions which emulate
    a random oracle in the following way: No efficient algorithm can
    distinguish (with significant advantage) between a function chosen
    randomly from the PRF family and a random oracle (a function whose
    outputs are fixed completely at random).

Informally, a PRF takes a secret key and a set of input values and produces
random-seeming output values for each input value. This is not the same as
a PRNG. SHA-256 is unkeyed and is not a PRF. A PRNG is a different concept
(though related)


   KDF            Key derivation function.  A particular specified use
                  of a PRF that takes a PSK, combines it with other
                  inputs to the PRF, and produces a result that is
                  suitable for use as a Traffic Key.

A KDF may or may not be based on a PRF. It does not necessarily take
a PSK (for instance, it might take a DH ZZ). There are other potential
outputs besides a traffic key.

   Security Association or SA  The parameters and keys that together
                  form the required information for processing secure
                  sessions between peers.  Examples of items that may
                  exist in an SA include: Identifier, PSK, Traffic Key,
                  cryptographic algorithms, key lifetimes.

This seems like a pretty IKE-centric defn.


   KMP            Key Management Protocol.  A protocol used between
                  peers to exchange SA parameters and Traffic Keys.
                  Examples of KMPs include IKE, TLS, and SSH.

TLS and SSH are not KMPs. They contain KMPs built in.


   Traffic Key    The actual key used on each packet of a message.

It's quite common to have two keys used for a single packet
(see for instance TLS).


1.2
   Four basic tactics may be employed in order to secure any piece of
   data as it is transmitted over the wire: privacy (or encryption),
   authentication, message integrity, and non-repudiation.  The focus
   for this effort, and the scope for this roadmap document, will be
   message authentication and packet integrity only. This work
   explicitly excludes, at this point in time, the other two tactics:
   privacy and non-repudiation.  Since the objective of most routing
   protocols is to broadly advertise the routing topology, routing
   messages are commonly sent in the clear; confidentiality is not
   normally required for routing protocols.  However, ensuring that
   routing peers truly are the trusted peers expected, and that no roque
   peers or messages can compromise the stability of the routing
   environment is critical, and thus our focus.  The other two
   explicitly excluded tactics, privacy and non-repudiation, may be
   addressed in future work.

This paragraph is fairly incoherent: privacy is a service. Encryption
is a technique/function. Authentication and message integrity are
services (I would typically say "data origin authentication").
Non-repudication exists in a different space: the technical service
we are interested in here is third-party verifiable integrity and
authentication, as opposed to that which is not third party verifiable
such as MACs. There is no reason to think that that's not a useful
service here, for instance, to avoid one member of a group security system
impersonating another. None of these are tactics. Incidentally, it's
not obvious to me that confidentiality is not desirable.


1.4. (6):
   6. Create a re-usable architecture, framework, and guidelines for
      various IETF working teams who will address these security
      improvements for various Routing Protocols.  The crux of the KARP
      work is to re-use that framework as much as possible across
      relevant Routing Protocols.  For example, designers should aim to
      re-use the key management protocol that will be defined for BGP's
      TCP-AO key establishment for as many other routing protocols as
      possible.  This is but one example.

As indicated above, I don't think this is obviously a good idea, both
because different environments demand different solutions and because
trying to design for maximum generality often leads to incoherent
design.



1.5.
   o  Message content security.  This work is being addressed in other
      IETF efforts, like SIDR.

What's "message content security". Surely we are interested in securing
the integrity of the protocol contents. I think I know what you mean
but this is unclear.


2.1.
There are lots of other situations in which keys get lost besides
employee termination. Why focus on this one.


   o  Brute Foce Attacks Against Password/Keys - This includes either
      online or offline attacks where attempts are made repeatedly using
      different keys/passwords until a match is found.  While it is
      impossible to make brute force attacks on keys completely
      unsuccessful, proper design can make such attacks much harder to
      succeed.  For exmaple, the key length should be sufficiently long

I don't agree that this is true in any practical sense. If your keys
are 256 bits long, then brute force attacks are effectively impossible.


3.
(3)
        identify weakness in algorithms is constant.  Breaking a cipher
        isn't a matter of if, but when it will occur.  It's highly

This doesn't seem obviously true at all. For instance, DES is still
very close to as secure as its key, even after 20+ years of attack
attempts.


(14)
   14.  The authentication mechanism in the Routing Protocol MUST be
        decoupled from the key management system used.  It MUST be
        obvious how the keying material was obtained, and the process
        for obtaining the keying material MUST exist outside of the
        Routing Protocol.  This will allow for the various key
        generation methods, like manual keys and KMPs, to be used with
        the same Routing Protocol mechanism.

I don't agree with this requirement, which precludes much of our effective
security technology, such as, for instance, TLS.


        3.   In an environment where both secured and non-secured
             systems are interoperating a mechanism MUST exist for
             secured systems to identify whether an originator intended
             the information to be secured.

This is not obviously possible in some settings.


DRAFT-IETF-KARP-DESIGN-GUIDE
2.1.
      Multicast protocols have unique security properties because of the fact
      that they are inherently group-based protocols and thus have group
      keying requirements at the routing level where link-local routing
      messages are multicasted.  Also, at least in the case of PIM-SM
      [RFC4601], some messages are sent unicast to a given peer(s), as is the
      case with router-close-to-sender and the "Rendezvous Point".  Some work
      for application layer message security has been done in the Multicast
      Security working group (MSEC, http://www.ietf.org/html.charters/msec-
      charter.html) and may be helpful to review, but is not directly
      applicable.

There is another unique issue here: spoofing of one group member by another.
Do you plan to address this?



3.1.
      The use of asymmetric keys can be a very powerful way to authenticate
      machine peers as are found in routing protocol peer exchanges. If
      generated on the machine, and never moved off the machine, these keys
      will be very secret, and will not be subject to change if an
      administrator leaves the organization. Since the keys are totally
      random, and very long, they are far less susceptible to off-line
      dictionary and guessing attacks.

If never moved off the machine is difficult to ensure w/o an HSM. You
oneed to explain this.


      An easy and simple way to use asymmetric keys is to start by having the
      router generate a public/private key pair. At the time of this writing,
      the keys in the pair SHOULD be no less than 2048bits long (though this
      length will grow over time). Many routers have the ability to be
      remotely managed over the SSH [RFC4252] and [RFC4253]. As such, they
      will also have the ability to generate and store an asymmetric key
      pair, because this is the commonly used method that users authenticate
      the SSH service when connecting to the router for management sessions.

This guidance strkes me as unwarranted. First, you fail to distinguish
between integer field based asymmetric algorithms and elliptic curve-based
algorithms, which have totally different key strength properties. A
2048-bit ECC key would be ludicrously long. Even if we confine ourselves
to integer algorithms, 1024-bit is suitable for many applications and
1536-bit is fine in most cases. Where does 2048 come from?

      Regardless which form we eventually standardize, the proof of this
      identity presentation can be as simple as the SHA-1 fingerprint, which
      is represented in a very human readable and transferable form of 20
      pairs of ASCII characters. More complexly, but also more securely, the

I wouldn't call a SHA-1 hash in hex "very human readable" as much as
"a huge pain in the ass"


3.2.
      Cryptographic keys must have a limited lifetime so that they are
      vulnerable against cryptanalysis attacks. Each time a key is employed,
      it generates a cipher text. In case of routing protocols the cipher
      text is the authentication data that is carried by the protocol
      packets. Using the same key repetitively allows an attacker to build up
      a store of cipher texts which can prove sufficient for a successful
      cryptanalysis of the key value.

This is simply false for any modern algorithm with any plausible amount
of data. Please do not say this.

      Another reason for limiting the lifetime of a key is to minimize the
      damage from a compromised key. It is unlikely a user will discover an
      attacker has compromised his or her key if the attacker remains
      "passive." Relatively frequent key changes will limit any potential
      damage from compromised keys.

Given that we're talking about keys which are used for integrity, this
guidance doesn't really make sense.


      Thus it is strongly recommended that routing and security protocols do
      not directly use the long-lived key, but should instead use a key
      derivation function to derive a short-lived key from the long-lived
      key.

This may or may not be good advice depending on the environment. For
instance, using the long-lived key for a lot of signing is just fine.


4.1.
         messages, etc.  To address brute force attacks [RFC3562] recommends
         a key management practice to minimize the possibility of successful
         attack-- frequent key rotation, limited key sharing, key length
         restrictions, etc.  Advances in computational power due to Moore's
         law are making that management burden untenable-- keys must be of a
         size and composition that makes configuration and maintenance
         difficult or keys must be rotated with an unreasonable frequency.  A
         KMP will help immensely with this growing problem.

This doesn't really make any sense. A sufficiently long key (80+ bits)
is strong enough to use for very long periods of time.  The
advantage gained by frequent rotation is simply minimal. (This is
easy to verify for yourself by simply arithmetic).

5.
         document, as well as its cryptography-helper document, TCP-AO-CRYPTO
         [I-D.ietf-tcpm-tcp-ao-crypto].  However, this cannot be used for LDP
         as LDP runs over UDP. A separate team might want to look at LDP.
         Another exception is the mode where LDP is used directly on the LAN.
         The work for this may go into the Group keying category (along with
         OSPF) as mentioned below.

I would observe that DTLS is a natural fit for LDP here.



7.1.
      keys aren't shared among multiple BGP peering arrangements, and (3)
      Keys SHOULD be changed at least every 90 days (this could be longer for
      stronger MAC algorithms, but it is generally a wise idea).

No, it's not a wise idea. It's a huge cost with almost no value.

If you're not going to provide an argument for this (and I don't
believe there is a good one) then please do not provide it as
guidance.



7.4.
This distinction between out-of-band versus in-line seems confusing.
There are at least three designs:

- Keys are centrally managed and imposed on endpoints.
- Endpoints do key management between each other but on a different
  channel than data traffic (e.g., IPsec)
- Endpoints do key management between each other on the same channel
  as data traffic (e.g., TLS)

I would call the last of these inline and the first and third both
out of band.

In light of this confusion the rest of this sxn doesn't work well
either.


DRAFT-IETF-KARP-FRAMEWORK
2.
I'm not at all convinced that this level of framework defn. is a good
idea. As I mentioned previously, it's not obvious you should decompose
the KMP from the data security piece. TLS and SSH do just fine without
this separation.

Second, why are we defining yet another abstract key store concept?
We already have PKCS #11 as well as per-platform stores like
SSH-agent and Apple Key Chain. Why is IETF getting into the game?

2.1.
It's important to distinguish proof of possession of a piece of
cryptographic keying material (a technical property) from
proof of identity (whatever that means, but in any case a social
property).

           of "approved thumbprints".  Self-signed certificates will
           have somewhat lower security properties than Certificate
           Authority signed certificates [RFC Certs].

This is not in general true. In fact, self-signed certs with
fingerprint exchange are *more* secure (though less convenient)
than PKIX certs because they are not subject to compromose if the CA.

                                                  This agreement is
   necessary in order for each to properly configure the connection on
   their respective devices.  The manner in which they agree upon and
   exchange this policy information is normally via phone call or
   written exchange, and is outside the scope of the KARP effort, but
   assumed to have occured.  We take as a given that each party knows
   the identity types and values, key types and values, and acceptable
   cryptographic algorithms for both their own device and the peer that
   form the security policy for configuration on their device.

I don't see why agreement on algorithms is necessary. One of the purposes
of a KMP is to allow negotiation and thus remove this kind of manual
agreement.


-Ekr