Subject: [karp] Review of threats-reqs

From: Eric Rescorla <[email-masked]>
Date: Thu, 29 Jul 2010 09:27:58 +0200

As I said at the mic, I had extensive comments on the threats-req
document. They're below under the head DRAFT-IETF-KARP-THREATS-REQS:

-Ekr

---------- Forwarded message ----------
From: Eric Rescorla <[email-masked]>
Date: Sun, Mar 21, 2010 at 3:19 AM
Subject: Review of karp documents
To: [email-masked]

$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