[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Son of IKE: A proposal for moving forward
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]
-----------------------------------------------------------