[karp] Review of karp documents
Eric Rescorla <ekr@rtfm.com> Sun, 21 March 2010 01:19 UTC
Return-Path: <ekr@rtfm.com>
X-Original-To: karp@core3.amsl.com
Delivered-To: karp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B41E23A6767 for <karp@core3.amsl.com>; Sat, 20 Mar 2010 18:19:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.247
X-Spam-Level: *
X-Spam-Status: No, score=1.247 tagged_above=-999 required=5 tests=[AWL=-0.506, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbJdiuwhJR6Q for <karp@core3.amsl.com>; Sat, 20 Mar 2010 18:19:54 -0700 (PDT)
Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by core3.amsl.com (Postfix) with ESMTP id BF8A93A65A6 for <karp@ietf.org>; Sat, 20 Mar 2010 18:19:53 -0700 (PDT)
Received: by gxk9 with SMTP id 9so2604543gxk.8 for <karp@ietf.org>; Sat, 20 Mar 2010 18:20:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.91.74.18 with SMTP id b18mr2548190agl.39.1269134391402; Sat, 20 Mar 2010 18:19:51 -0700 (PDT)
Date: Sat, 20 Mar 2010 18:19:51 -0700
Message-ID: <d3aa5d01003201819g6c72ef6dkb185bdc1061dc360@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
To: karp@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [karp] Review of karp documents
X-BeenThere: karp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion list for key management for routing and transport protocols <karp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/karp>, <mailto:karp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/karp>
List-Post: <mailto:karp@ietf.org>
List-Help: <mailto:karp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/karp>, <mailto:karp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Mar 2010 01:19:55 -0000
$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
- [karp] Review of karp documents Eric Rescorla
- Re: [karp] Review of karp documents Bhatia, Manav (Manav)
- Re: [karp] Review of karp documents Eric Rescorla
- Re: [karp] Review of karp documents Christopher Morrow
- Re: [karp] Review of karp documents Vishwas Manral
- Re: [karp] Review of karp documents Eric Rescorla
- Re: [karp] Review of karp documents Vishwas Manral
- Re: [karp] Review of karp documents David McGrew
- Re: [karp] Review of karp documents Vishwas Manral