[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Son of IKE: A proposal for moving forward




Ted,

The one thing I don't see here is any
consideration of the very basic question of
whether there are in fact two different problem
spaces. The slant of this working group is very
VPN-centric, much to the burden of things which
aren't especially interested in remote access,
amortization of authentication expense, etc, etc.
While this doesn't directly speak to favoring JFK
or IKEv2, the design decisions of JFK are much
more favorable to producing a streamlined key
management protocol.

The problem I see here is that almost any question
you ask which implies added functionality is going
to have _some_ constituency who is going to be
extremely vocal about keeping their favorite
feature (cf pre-shared keys, quick mode...).  What
is completely lost here is those implementations
which *don't* need the added functionality and
*don't* want the added cost both of complexity and
footprint. As far as I can tell, this side of the
argument is essentially voiceless.

	    Mike

Theodore Ts'o writes:
 > 
 > A few weeks ago, a group of people composed of folks from the IKEv2 and
 > JFK camps, plus one or two interested observers (such as Paul Hoffman)
 > got together and created a "SOI-features" document.  This document was
 > supposed to contain a comparison of the two proposals, and a set of
 > alternatives which the IPSEC working group was supposed to consider and
 > select between.  Once the IPSEC wg had answers the questions contained
 > in this draft, this design team had promised to craft a combined,
 > compromise protocol which reflected the desire of the working group with
 > respect to certain key requirements questions.
 > 
 > Unfortunately, there has not been much in the way of responses to this
 > draft.  In attempt to try to drive this process forward, Barbara and I
 > have distilled a set of short, succinct questions which were implicit in
 > the soi-features I-D.  We have also correlated implications from the IKE
 > requirements documents as listed in section 9 of the soi-features I-D.
 > (Some of the highlighted links in section didn't really make sense to us
 > when we did this exercise, but we just cut and pasted from section 9 to
 > the relevant set of questions from sections 2 through 6.  If folks could
 > help us fill in the "implications from scenarios" section with references
 > to Cheryl Madson's requirements document, we would greatly appreciate
 > it.  Ideally for each question and each sceario, we should be able to
 > state whether a particular scenario requires a "yes", "no", or "don't
 > care' answer for each question.  Help in providing these answers will
 > make the working group's job much easier.)
 > 
 > What we next propose to do is to feed these questions to the working
 > group in piece meal fashion --- every day, we will send one or more
 > subsection's worth of questions to the mailing list, and we will expect
 > the working group to look at these questions (which hopefully will be a
 > little more digestible than the original soi-features draft) and provide
 > answers to them.  If we do not receive answers, Barbara and I reserve
 > the right to choose answers to these questions ourselves, possibly using
 > a coin flip if we feel so motivated.  :-)
 > 
 > Before we start this process, we would like the working group to look
 > over this overall set of questions, and tell us if we have properly
 > distilled them from the soi-features draft, and whether any questions
 > might be missing from this set.  There are a few places where the
 > soi-features draft went in very great detail about how JFK or IKEv2
 > implemented a particular feature, but we wouldn't see any real
 > difference between the two design choices.  Hence, there was no real
 > question to be asked by the working group.  If the JFK or IKE teams feel
 > that we have missed some point about how their proposal is
 > overwhelmingly superior, please tell us what we missed, and please
 > suggest an alternate question for that subsection.
 > 
 > Please send us comments by the end of this week (i.e., June 14th) if at
 > all possible; we'd like to start the process of feeding individual
 > questions to the ipsec mailing list next week (i.e., starting Monday,
 > June 17th)
 > 
 > 					- Ted and Barbara
 > 
 > 		      ----------------------------
 > 
 > 	    Questions derived from the SOI Features document
 > 	      Created by Barbara Fraser and Theodore Ts'o
 > 
 > 2. Cryptographic features
 > 
 > 2.1 Identity protection: who is protected, kinds of attacks
 > 
 > 2.1.A.)  Does SOI need to provide protection against passive
 > attacks for the initiator?
 > 
 > 2.1.B.)  Does SOI need to provide protection against active
 > attacks for the initiator?
 > 
 > 2.1.C.)  Does SOI need to provide protection against passive
 > attacks for the responder?
 > 
 > 2.1.D.)  Does SOI need to provide protection against active
 > attacks for the responder?
 > 
 > Implications from the Scenarios:
 > 
 > VPN: <<<In a multiple administrative domain network, identity
 > protection of both IPsec endpoints is important.>>> [[[2.1]]]
 > 
 > End-to-End: <<<Hiding the identity of both parties in the exchange is
 > desirable.>>> [[[2.1]]]
 > 
 > 
 > -----------------------------------------------------------
 > 2.2 Perfect forward secrecy (PFS)
 > 
 > 2.2.A) JFK and IKEv2 can provide PFS as well as "imperfect forward
 > secrecy" by trading off performance versus the level of PFS provided.
 > The funcitonality provided is roughly identical.  Does anyone care
 > about the details of how IKEv2 versus JFK provides this functionality?
 > Should we just flip a coin?
 > 
 > Implications from the Scenarios:
 > 
 > [none]
 > 
 > 
 > -----------------------------------------------------------
 > 
 > 2.3 Authentication styles
 > 
 > 2.3.A.)  Does SOI need to natively support "legacy authentication
 > systems"?
 > 
 > 2.3.B.)  Does SOI need to natively support some kind of "shared
 > secret" scheme?
 > 
 > (Note. If SOI is provides cert-only, then one would need to use
 > another protocol to bootstrap certificates from a legacy
 > authentication or shared secret scheme.)
 > 
 > Implications from the Scenarios:
 > 
 > VPN:  <<<In the case of dynamic IP addresses and/or NAT boxes, IP
 > addresses cannot be used as phase 1 identifiers. This also means that
 > the authentication material cannot be chosen based upon the IP address
 > in the packet.>>> [[[2.3]]]
 > 
 > SRA: <<<This means that there must be a way of securely pushing down
 > this policy information before the IPsec tunnel is constructed.>>>
 > [[[2.3]]]
 > 
 > SRA: <<<The mechanism associated with such authentication should
 > accommodate re-authentication based on the RAS or authentication
 > server site security policy>>> [[[2.3]]]
 > 
 > SRA: <<<Out-of-band authentication mechanisms must also consider the
 > location of the authentication server relative to the client and the
 > RAS. In many scenarios, server tends to be "behind" the RAS device, in
 > the domain that is being secured by the RAS, which may be problematic
 > for bootstrapping the user authentication for the client-to-RAS
 > connection.>>> [[[2.3]]]
 > 
 > 
 > -----------------------------------------------------------
 > 
 > 2.4 Number of crypto operations
 > 
 > 2.4.A) JFK requires substantially more cryptographic operations for
 > rekeying (two more signatures, two more signature validations, and
 > three more hashes).  Is this a problem?  More generally, does SOI need
 > to be able to support "fast" rekeying?
 > 
 > -----------------------------------------------------------
 > 
 > 2.5)  Plausible denaibility 
 > 
 > 2.5.A) Does SOI need to provide "plausible deniability" (the opposite
 > of "non-repudiation") for the initiator?
 > 
 > 2.5.B) Does SOI need to provide "plausible deniability" (the opposite
 > of "non-repudiation") for the responder?
 > 
 > Implications from the Scenarios:
 > 
 > [none]
 > 
 > -----------------------------------------------------------
 > 
 > 2.6 Formal proofs of security
 > 
 > 2.6.A)  Does SOI need to provide a formal proof of security?  (Is this
 > a "must have" or a "nice to have"?  What are we willing to trade-off
 > for having a formal proof of security?)
 > 
 > Implications from the Scenarios:
 > 
 > [none]
 > 
 > -------------------------------------------------------------
 > 
 > 3. Protocol mechanics
 > 
 > 3.1 DoS protection
 > 
 > 3.1.A) WRT DOS attacks that exhaust memory or CPU resources, is it more 
 > important to always keep the message count at 4, or is it acceptable to add 
 > an additional roundtrip of messages when the responder thinks he's under 
 > attack?
 > 
 > 3.1.B) WRT UDP fragmentation attack protection, both IKEv2 and JFK provide 
 > basically equivalent protection. Does anyone care about the details of how 
 > JFK or IKEv2 provide this functionality.
 > 
 > 3.1.C) Is it important to have precomputation of exponentials available for 
 > use as a mechanism for protecting against cpu consumption attacks?
 > 
 > Implications from the scenarios:
 > 
 > [none]
 > 
 > --------------------------------------
 > 
 > 3.2 Number of messages in all scenarios
 > 
 > 3.2.A)In both IKEv2 and JFK, Alice chooses a Diffie-Hellman group in 
 > message one. In IKEv2 if Bob doesn't accept what Alice offers the 
 > negotiation starts again. In JFK if Bob doesn't accept what Alice offers 
 > but Alice can live with what Bob offers, they continue. Otherwise they 
 > start over. Is this an important feature for SOI?
 > 
 > Implications from the scenarios: 
 > 
 > SRA: <<<This means that the key management mechanism must be able to
 > rapidly establish both the SOI and IPsec connections, without undue
 > impact on CPU and memory overhead. It's also desirable for each
 > exchange to have as few messages as possible, to help alleviate the
 > burst load on the RAS.>>> [[[3]]] See also 4.2, 2.4
 > 
 > 
 > --------------------------------------
 > 
 > 3.3 Size of messages
 > 
 > There is no significant difference in the size of messages in the two 
 > protocols.
 > 
 > Implications from the scenarios:
 > 
 > [none]
 > 
 > --------------------------------------
 > 
 > 
 > 3.4 Preferred ID for responder
 > 
 > 3.4.A) In JFK and IKEv2, the initiator can include a payload is an 
 > indication to the responder as to what identity (and corresponding key 
 > material) the responder should use to authenticate to the initiator. In 
 > JFKr and IKEv2, this value is encrypted in message 3; in JFKi, it is sent 
 > in the clear in message 1, thereby allowing a passive attack on the 
 > responder's likely identity. Is it important to encrypt this identity?
 > 
 > Implications from the scenarios:
 > 
 > [none]
 > 
 > --------------------------------------
 > 
 > 
 > 3.5 Birth certificates
 > 
 > See 4.3 for discussion on this and DPD
 > 
 > 
 > -----------------------------------------------------------
 > 
 > 4. One or two phases
 > 
 > 4.1 Control channel vs. separate protocols
 > 
 > 4.1.A) [Meta question, that will be answered by the other questions in
 > section 4.]  Does SOI need a control channel for SA management?  Or is
 > it acceptable to piggy back SA management as a part of other parts of
 > the SOI protocol?
 > 
 > Implications from the Scenarios:
 > 
 > VPN: <<<This calls out a need for either a two-phased approach for
 > SOI, or a single-phased approach that is sufficiently fast, where
 > "fast" represents an optimal combination of "number of messages" and
 > "computational expenditure".>>> [[[4.1]]]
 > 
 > 
 > 
 > -----------------------------------------------------------
 > 
 > 4.2 Creating multiple SAs for a single pair of entities
 > 
 > 4.2.A) How important is it that SOI be able to create multiple SA's
 > between a pair of entities "cheaply"?
 > 
 > 4.2.B) How often will usage scenarios of SOI need to generate multiple
 > SA's between a single pair of entites?
 > 
 > Implications from the Scenarios:
 > 
 > VPN: <<<The cost of authentication must also be factored into the
 > total cost; this will be different for different mechanisms, which
 > results in a decision of scalability -vs- processing overhead. In
 > certain cases, it may be desirable to amortize the cost of the key
 > management across multiple tunnels.>>> [[[4.2]]]
 > 
 > VPN, End-to-END, SRA : <<<QoS increases the probability of multiple
 > tunnels between a pair of SGWs. Also, negotiation of IPsec tunnels
 > needs to accommodate QoS information, predominantly in the set of
 > selectors used to identify the contents of any particular IPsec
 > tunnel.>>> [[[4.2]]]
 > 
 > SRA: <<<While this does not mandate user authentication to happen
 > within the SOI exchange, it's strongly encouraged that the protocol
 > directly or indirectly associate a single user authentication exchange
 > with a group of IPsec tunnels between a client and an RAS.>>>
 > [[[4.2]]]
 > 
 > SRA: <<<For example, this may mean that SOI will need to allow for the
 > client to present its identity (or some "blob of bits" that the server
 > can correctly map to an identity) early in the exchange.>>> [[[4.2]]]
 > 
 > -----------------------------------------------------------
 > 
 > 
 > 4.3 Dead peer detection
 > 
 > 4.3.A) Both JFK and IKEv2 provide dead peer detection via a
 > "keep-alive" mechanism.  The functionality provided is roughly
 > identical.  Does anyone care about how low-level implementation
 > details of IKEv2 and JFK?
 > 
 > 4.3.B) Should the working group consider other schemes which provide
 > the same functionality as dead peer detection?  (i.e., birth
 > certificates, see section 3.5 in draft-ietf-ipsec-soi-features-01.txt)
 > 
 > Implications from the Scenarios:
 > 
 > [none]
 > 
 > -----------------------------------------------------------
 > 
 > 4.4 SA deletion
 > 
 > 4.4.A) Both JFK and IKEv2 provide SA deletion.  The functionality
 > provided is roughly identical.  Does anyone care about how low-level
 > implementation details of IKEv2 and JFK?
 > 
 > Implications from the Scenarios:
 > 
 > [none]
 > 
 > -----------------------------------------------------------
 > 
 > 4.5 SA rekeying
 > 
 > 4.5.A) Both JFK and IKEv2 provide SA rekeying.  The functionality
 > provided is roughly identical, although JFK requires more
 > cryptographic operations to do rekeying (see 2.4).  Does anyone care
 > about how low-level implementation details of IKEv2 and JFK?
 > 
 > Implications from the Scenarios:
 > 
 > [none]
 > 
 > -----------------------------------------------------------
 > 
 > 4.6 Authenticated error messages
 > 
 > 4.6.A) Both JFK and IKEv2 provide authenticated error messages.  The
 > functionality provided is roughly identical, although details very
 > different due to the lack of a 2 phase protocol in JFK.  Does anyone
 > care about how low-level implementation details of IKEv2 and JFK?
 > 
 > Implications from the Scenarios:
 > 
 > [none]
 > 
 > -----------------------------------------------------------
 > 
 > 4.7 Authenticated informational messages
 > 
 > 4.7.A) Does SOI need to provide authenticated informational messages
 > after an IKE SA has been set up?  (What sort of informational messages
 > might be needed?  Do they need to be protected in a different key than
 > the SA key?)
 > 
 > Implications from the Scenarios:
 > 
 > [none]
 > 
 > -----------------------------------------------------------
 > 
 > 5. SA creation style
 > 
 > 5.1 Cryptographic agreement
 > 
 > 5.1.A)Is negotiation for the algorithm suite required or not?
 > 
 > 5.1.B) Is there ever a case when you want the initiator to have the "last 
 > word"?
 > 
 > Implications from the scenarios:
 > 
 > [none]
 > 
 > --------------------------------------
 > 
 > 5.1.2 Agreement of IPsec SA cryptographic algorithms
 > 
 > JFK's SA negotiation uses pre-defined suites, and Bob presents a single 
 > suite to Alice. In IKEv2 SA negotiation allows the two parties to agree on 
 > the most preferred parameters, the same as it does for key negotiation.
 > 
 > 5.1.2.A) Is it important to allow negotiation of the SA algorithms?
 > 
 > Implications from the scenarios:
 > 
 > [none]
 > 
 > --------------------------------------
 > 
 > 5.2 Scope of proposals
 > 
 > 
 > 5.2.A) Is it important to have predefined suites or a la carte selection of 
 > parameters?
 > 
 > 
 > Implications from the scenarios:
 > 
 > [none]
 > 
 > --------------------------------------
 > 
 > 5.3 SPD entries
 > 
 > 
 > 5.3.A) Is it important in SOI to allow the the responder to accept a subset 
 > of the proposed SA, or should it be an all or nothing acceptance?
 > 
 > 5.3.B) Should the SOI offer multiple selectors with specific ports and
 > addresses, or a single selector with a range of ports and range of
 > addresses?  (complicated boolean complexity!)  
 > 
 > Implications from the scenarios:
 > 
 > <<<In the case of a pair of SGWs fronting multiple non-contiguous
 > subnets, a mechanism that allowed the negotiation of a list of phase 2
 > identities will help to alleviate the number of IPsec tunnels that must
 > be created.>>> [[[5.3]]]
 > 
 > --------------------------------------
 > 
 > 6. Wire protocol issues
 > 
 > 6.1 Message encoding
 > 
 > 6.1.A) Should SOI worry about aligning parts of messages on 2 and 4
 > byte boundaries?
 > 
 > 6.1.B)  Should SOI tag its protocol with version numbers?
 > 
 > 6.1.C) Should SOI format be roughly the same as IKEv1?  (See
 > discussion in section 6.4, re: code preserving)
 > 
 > Implications from the Scenarios:
 > 
 > -----------------------------------------------------------
 > 
 > 6.2 Port number
 > 
 > 6.2.A) Should SOI use the same port as IKEv1?  (See discussion in
 > soi-features-01 the tradeoffs in this question).
 > 
 > Implications from the Scenarios:
 > 
 > [none]
 > 
 > -----------------------------------------------------------
 > 
 > 6.3 Future versions of the protocols
 > 
 > 6.3.A) Should SOI have a mechanism for demanding/requesting that a
 > peer use a particular version of IKE/SOI to allow upgrading to new
 > versions?
 > 
 > Implications from the Scenarios:
 > 
 > [none]
 > 
 > -----------------------------------------------------------
 > 
 > 6.4 Code-preservingness
 > 
 > 6.4.A) Is it important that SOI allow some amounts of an IKEv1
 > implementation be reusable when creating an SOI implementation?
 > 
 > 
 > Implications from the Scenarios:
 > 
 > IPS: <<<[ietf-ips-security-xx.txt] discusses resource constraints,
 > calling out the size for both code footprint and data as the most
 > important criteria.>>> [[[6]]]
 > 
 > 
 > -----------------------------------------------------------
 > 
 > 6.5 Extensibility of the protocols
 > 
 > 6.5.A) Should SOI have mechanisms for allowing extensions to the SOI
 > protocol?
 > 
 > 6.5.B) Should SOI need a way to mark new extensions as critical?
 > (i.e. If you don't understand a critical extension you must fail the
 > entire negotiation)
 > 
 > Implications from the Scenarios:
 > 
 > VPN, End-to-End, : <<<Extensions to the IPsec (now known as phase 2)
 > parameters are needed in order to negotiate QoS characteristics for
 > the various tunnels.>>> [[[6.5]]]
 > 
 > IPS: <<<However, the discussion in [ietf-ips-security-xx.txt] calls out
 > requirements for an API, in order to provide a means of pushing
 > authentication information to the application (e.g. "this peer was
 > authenticated with this cert"), so the application can decide what types
 > of transactions are allowed by this peer.>>> [[[6.5]]]
 > 
 > PPVPN/MPLS: <<<it may make sense to expand the set of phase 2
 > identifiers to also support an MPLS/VPN identifier (so the entity
 > doing the SPD check can be separated from the entity doing the
 > encapsulation).>>> [[[6.5]]]
 > 
 > Implications from the Scenarios:
 > 
 > [none]
 > 
 > -----------------------------------------------------------