[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Moving forward with IKE V2: A proposal for final edits to ikev2-04
<snip>
> 3) For the Cipher Suite issue, that we use Paul Hoffman's proposed set
> of Cipher suites. There is less consensus on this issue on the
> mailing list, but most people don't seem to have strong feelings,
> so we believe we just pick something:
>
> Suite-ID Meaning
> -------- -------
> 0 Covers: IKE (MUST)
> 168-bit 3DES CBC encryption
> Diffie-Hellman group 2 (1024-bit)
> HMAC-SHA1 integrity and prf
>
> 1 Covers: ESP (MUST)
> 3DES encryption with three keys
> HMAC-SHA1 integrity
>
> 2 Covers: AH (SHOULD)
> HMAC-SHA1 integrity
>
> 3 Covers: IKE (MUST)
> 168-bit 3DES CBC encryption
> Diffie-Hellman group 5 (1536-bit)
> HMAC-SHA1 integrity and prf
>
> 4 Covers: IKE (MUST)
> AES encryption in CBC mode with 128-bit keys
> Diffie-Hellman group 5 (1536-bit)
> HMAC-SHA1 integrity and prf
>
> 5 Covers: IKE (MUST)
> AES encryption in CBC mode with 128-bit keys
> Diffie-Hellman group 14 (2048-bit)
> HMAC-SHA1 integrity and prf
>
> 6 Covers: ESP (MUST)
> AES encryption in CBC mode with 128-bit keys
> HMAC-SHA1 integrity
>
> 7 Covers: IKE (SHOULD)
> AES encryption in CTR mode with 128-bit keys
> Diffie-Hellman group 14 (2048-bit)
> AES-CBC MAC + XCBC integrity and prf
>
> 8 Covers: ESP (SHOULD)
> AES encryption in CTR mode with 128-bit keys
> AES-CBC MAC + XCBC integrity
>
> I have adjusted the MUST/SHOULD from Paul's message since I
> believe that
> for implementations that will be moving to implement IKEv2, it is
> reasonable to require the implementation of AES, as it as so many
> advantages over 3DES. If it weren't for the existing chips that only
> support AES-CBC, I'd argue for making AES-CTR mandatory instead, but
> given where we are, this set of MUST/SHOULD seems to me to be the most
> reasonable set of ciphers.
>
> Question: Should AES Counter mode be made mandatory to ensure
> compatibility in the future? Existing chips only support AES-CBC, so
> this might make things harder for people as they transition
> to IKEV2. On
> the other hand, by the time we see start seeing IKEv2
> products, it might
> be reasonable to require the presence of AES-CTR support.
As far as SHOULD vs. MUST goes w.r.t. cipher algorithms - I think
leaving it
at SHOULD would suffice. Experience with 3DES showed that even though
it
was a "SHOULD" most people ended up implementing it. To this end, I
guess
support for such algorithms is very demand-based.
> -----------------------------------
>
> (SEMI-)CLOSED ISSUES
> =====================
>
> The following issues have been burbling on the list, although in the
> opinion of the IPSEC Working group chairs, there isn't
> consensus in the
> IPSEC working group to act on them.
>
> If you feel otherwise, please speak now.
>
> A) Revised identity
> --------------------
>
> Paul Hoffman has a proposal, draft-ietf-ipsec-revised-identity-00.txt,
> which radically changes how identities are handled. Specifically, it
> would eliminate the ID payload with the following types:
>
> ID_IPV4_ADDR 1
> ID_FQDN 2
> ID_RFC822_ADDR 3
> ID_IPV6_ADDR 5
> ID_DER_ASN1_DN 9
> ID_DER_ASN1_GN 10
> ID_KEY_ID 11
>
> et.al, and replaces it with a FullID payload with the following types:
>
> 1 PKIX certificate
> 2 Certificate bundle
> 3 Hash-and-URL of PKIX certificate
> 4 URL to a PKIX certificate bundle
> 5 PKIX keyIdentifier
> 6 IDForSharedSecret
>
> This would be fundamental change in the management and
> administraton of
> IPSEC and IKE, so is not something to adopt lightly, and
> without a clear
> consensus of the working group. This was discussed in two threads on
> the IPSEC mailing list: one starting on November 5th (subject Adding
> revised identities to IKEv2), and one starting on December
> 8th (subject:
> Summary of revised identity changes). People who spoke in
> favor on the
> mailing list included Francis Dupont and Bill Sommerfeld,
> with qualified
> support from Michael Richardson (if support for bare keys is
> added) and
> Tero Kivinen (who is concerned about the complexity of the proposal).
>
> This proposal was discussed in Atlanta, but Charlie, Barbara, and Ted
> were left with the impression that there was not consensus among those
> who met to discuss legacy authentication after the IPSEC wg meeting to
> pursue adoption of Paul's proposed change. Paul believes otherwise.
> Since it is the job of working group chairs to determine consensus, we
> (Barbara and Ted) hereby ask that those who believe we should
> pursue the
> revised identity proposal to please speak up.
>
> It should be noted that there are some intermediate positions beyond
> what is currently in draft-ietf-ipsec-ikev2-04.txt and the
> revised-identies draft. For example, we could add the
> Hash-and-URL type
> to the Certificate payload, if the goal is shrink the size of IKE
> messages (with the tradeoff of increasing complexity in IKE
> implementations). We could also add a CERT hash type to the ID
> payload, without nuking the traditional FQDN or IPv4/6 addresses
> identity mechanisms (although again, by adding new types, we would be
> increasing the complexity of the specification and implementations).
>
> Due the relatively small number of people who have spoken in favor of
> this proposal or its less-radical alternates, the default choice for
> IKEv2 has to be what is currently in ikev2-04. So those who
> believe we
> should make this change (or those who strongly believe we should not)
> are requested to speak up now, or forever hold your peace....
I'm all for clearing up the vagaries of the ID payload - especially when
using certificates. But the proposed change seems to weigh heavily on
certificate ID types - despite the fact that authentication by preshared
key seems to be the preferred method. I admit that the hesitance to
adopt certificates could arise from the ID confusion; still I feel more
comfortable with the familiar ID types we currently have when using
preshared key. Given this, couldn't we just be more explicit about what
goes in an ID payload when certs are used?...and perhaps take the
hash-and-url option from Paul's proposal?
> B) DHCP-based vs. MODECFG style remote access configuration
> -----------------------------------------------------------
>
> Currently, draft-ietf-ipsec-ikev2-04.txt handles remote access via a
> Configuration payload with defined attributes. An alternate mechanism
> involves using tunneled DHCP requests. The latter approach
> is about to
> be published as an RFC by the IPSRA working group. Proponents of this
> method argue that it is more powerful than modecfg (because of the
> extensibility and large number of options already specified for DHCP;
> for example, being able to specify DNS, time, print, or WINS servers,
> and so on.) It is also argued that it requires less code on the
> server/firewall, since an existing DHCP server can be used.
>
> Proponents of the modecfg approach argue that many implementation
> already have support for modecfg, and that setting up sort-lived
> specialized tunnels to allow the DHCP packets to flow through the
> gateway is kludgy, and requires multiple special case entries into
> packet forwarding tables. Modecfg proponents also argue that
> it is also
> possible to transform modecfg requests into DHCP requests, so
> there are
> implementation choices that do not require reimplementation of the
> DHCP's address assignment function. They also point out that it
> certainly is possible --- and in some ways easier --- to obtain the
> time, print, WINS server information by using DHCP (via the DHCPINFORM
> request) after the IPSEC tunnel is setup and the client address is
> assigned.
>
> Either approach seems to be workable. It is certainly true
> that most of
> the people in Atlanta were implementors who were already familiar with
> modecfg, representing a large implementation community. That being
> said, there is also some number of working group members that are in
> favor of an approach similar to draft-ietf-ipsec-dhcp-13,
> including Van
> Aken Dirk, Michael Richardson, and Scott G. Kelley. One way or
> another, however we need to make a choice and move forward.
>
> Given that we have a fully specified solution in the ikev2-04
> draft, and
> it would seem that while there is a sizeable minority in favor of the
> ipsec-dhcp-13 approach, the majority are comfortable with the modecfg
> based approach. So at this point, we, as working group chairs, judge
> that the consensus is with the current approach.
>
> If there are those who feel otherwise, or who see fatal problems with
> the current approach, please speak now.
I never thought I'd be a defender of mode config, but here I'm about to
defend it. I prefer mode config to dhcp-ipsec for several reasons:
- as implementors, we understand it. We have experience implementing
it, we're comfortable with its extensibility.
- Mode config allows us to use various data stores for housing policy -
be it the security gateway itself, RADIUS, etc. Note that using mode
config shouldn't preclude us from getting address pools from a dhcp
server, even.
- Mode config allows us to decide on address pools based on the identity
of the peer.
One argument in favor of DHCP that I've read on this list is that it's
an existing protocol with many configuration parameters already defined.
I can certainly see the benefit of this (no point in reinventing the
wheel), but I think it's worth noting that, since mode config is part of
the IKE realm, IKE implementors control its extensibility. It might be
too restrictive to depend on DHCP to come up with parameters that might
be IKE-centric (if we were ever to need to extend configuration
options).
-g
> Ted and Barabara
> IPSEC wg chairs
>