Subject: Re: suites vs. a la carte and IPcomp in IKEv2-05

From: [email-masked]
Date: Mon, 3 Mar 2003 21:19:36 -0500

For people advocating that the working group reconsider the suites vs. a la
carte decision, it might help clarify things if you specified whether you
advocated a la carte as specified in ikev2-02 or whether you preferred some
alternate encoding of offers and the accepted combination (and if so, what
encoding). It would also be helpful if you specified how each of the
attributes listed below should be negotiated (if different from ikev2-05).

There seems to be some confusion over exactly what's negotiated as part of
a suite and what's not in ikev2-05. Even advocates of suites might want
some different organization. Currently, the following attributes of SAs are
negotiated as a suite:

ESP vs AH vs IKE SA
Diffie-Hellman Group
Encryption Algorithm (including mode and key size)
Integrity Protection Algorithm (including whether Extended Sequence Numbers
are used)
PRF Algorithm (for IKE SAs only)

There are some other SA attributes that are negotiated independently.

Compression algorithms (IPcomp) are proposed by the initiator and selected
(or not) by the responder. By not including compression algorithms in the
cryptographic suites, we avoid the multiplicative explosion we should get
in the likely case that implementations supported multiple suites and
multiple compression algorithms. What we lose is the ability to offer Suite
1 with LZS or Suite 2 with DEFLATE but not Suite 1 with DEFLATE or Suite 2
with LZS. So far, no one has made a case for needing that flexibility and
several people have pointed out the perils of including compression in the
cryptographic suite.

Transport Mode (vs. tunnel) is proposed by the initiator and accepted (or
not) by the responder. Support for transport mode is optional. There is a
presumption that if the initiator proposes transport mode that she would
prefer to use it. There is a presumption that if the responder does not
support transport mode, that the initiator will accept an SA in tunnel mode
with the same cryptographic suite. If that's not true in some
implementation, the initiator would have to close the SA without using it.
And as with compression, there is no ability to offer Suite 1 with
transport Mode or Suite 2 with tunnel mode but not the other combination.

Explicit Congestion Notification was negotiated in IKEv1 but a single
algorithm (not negotiable) is specified for all SAs negotiated with IKEv2.
No one (yet) has argued for the ability to negotiate alternate ECN
protocols, much less to make such negotiation tied in with cryptographic
suites. I would imagine that should we need such negotiation in the future,
it would be negotiated independently of the other SA attributes.

UDP Encapsulation for NAT Traversal was negotiated in IKEv1 but is not in
IKEv2. UDP Encapsulation is unilaterally selected by the initiator in IKEv2
upon detecting a NAT, and any SA negotiated via an encapsulated IKE SA will
also be encapsulated using the same UDP ports.

Authentication Algorithm is unilaterally selected by the initiator in
IKEv1. In IKEv2, each end chooses its own authentication algorithm
(sometimes with hints from the other end as to what is supported).

SA Lifetime was negotiated in IKEv1. In IKEv2, each end independently
chooses an SA Lifetime and whoever has the shorter one will initiate a key
rollover.

A case could be made for negotiating use of Extended Sequence Numbers
independently from crypto suite in a manner similar to transport vs tunnel
mode. I proposed including it in crypto suite because I assumed that the
only reason to not use ESNs was for backwards compatibility and that all
new cryptographic suites would require them.

          --Charlie

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Francis Dupont <[email-masked]>
Date: Tue, 04 Mar 2003 12:22:00 +0100

In your previous mail you wrote:

=> the IKEv2 mechanism has to be revised because it is subject to
a bidding down attack. Can we open a thread about this?

Thanks

[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 04 Mar 2003 14:37:05 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Francis" == Francis Dupont <[email-masked]> writes:
    Francis> => the IKEv2 mechanism has to be revised because it is subject
    Francis> to a bidding down attack. Can we open a thread about this?

  As I understood things, this issue is not that a third party can 
force UDP encapsulation of the ESP packets by playing with the UDP
headers of the IKE exchange.

  The issue is that said attacker can force all transmissions from the
gateway to the client to go via itself. It does this by pretending to
be a NAT, and futzing with the source IP/port#. The gateway will use that
address for the packets it sends. 
  We can not, in general have the gateway refuse to change its notion of
where to send things because: 
       1) the attacker could have started futzing at the beginning of the
	  exchange anyway.
       2) a NAT may legitimately assign new port numbers/IP addresses to
	  the flow.

  So, what in the end is the effect of having the IKE/ESP flow sent via
some malicious third party? Assuming that the third party does not drop
any packets in the flow, we have:
     a) additional latency. 
     b) traffic analysis.
     
  I assume that the crypto is good. If it isn't, and the attacker can break
the crypto, all bets are off anyway.

  The most serious thing that the third party can do is to hijack the flow
with the intent to disrupt the flow. This is a denial of service attack.

  I have a notion on how to deal with this, but before I get into it,
I'd like be sure that we are solving the right problem.

  The problem is: is there a way for the client/gateway to agree that they
have a functional UDP pipe between each other before committing to a change.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Francis Dupont <[email-masked]>
Date: Wed, 05 Mar 2003 16:54:18 +0100

-----BEGIN PGP SIGNED MESSAGE-----

   
=> there are two things, the bidding down attack and the attack using
the NAT traversal. Your text is about the second: it is useful but
it is not the bidding down attack, i.e., it is just an explaination
of the "bidding down".

     The issue is that said attacker can force all transmissions from the
   gateway to the client to go via itself.

=> not itself but someone.

   It does this by pretending to

   

=> yes, the main issue is the DoS attack. IKE itself is secure but
it can be (ab)used to launch attacks.

=> there is none.

It seems we agree that the NAT traversal feature is less secure so:
 - it should be disabled when one knows there cannot be a NAT on the path.
 - the NAT detection should be safe, i.e., it should not give false
   positive. This is my "bidding down" argument against the current
   mechanism (which has many other problems but one is enough).

Thanks

PS: the bidding down attack itself is obvious: the attacker has only to
change a NAT-DETECTION-*-IP in the IKE_SA_INIT reply.
PPS: the reference about attacks using IKE (not against IKE) is
draft-dupont-transient-pseudonat-01.txt

---

From: [email-masked]
Date: Tue, 4 Mar 2003 23:12:56 -0500

> address for the packets it sends.

I would claim that an attacker can only do this if it is on the path
between the two IPsec endpoints. The attacker would have to prevent
delivery of the packet with the original IP address/port # and send a
packet with the same innards but a different source IP/port#. At this
point, I would claim the attacker *is* a NAT, since that's exactly what
NATs do.

> any packets in the flow, we have:

But any party on the path between the two IPsec endpoints can do this
anyway - with or without invoking NAT-T.

That's not to say that these threats aren't serious. Just that there is
nothing we could possibly do within IKE or ESP to improve the situation.

What am I missing?

          --Charlie

---

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Mar 2003 12:22:18 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Charlie" == Charlie Kaufman <[email-masked]> writes:
    >> be a NAT, and futzing with the source IP/port#. The gateway will use
    >> that address for the packets it sends.

    Charlie> I would claim that an attacker can only do this if it is on the
    Charlie> path between the two IPsec endpoints. The attacker would have to
    Charlie> prevent delivery of the packet with the original IP address/port

  Well, they do not need to be in the reverse path.
  It enough to be in the forward path.  (client->gateway)

  The replay protection means that it isn't enough to replay the packet,
unless one can do it faster than the original packet. So, I agree that the
attacker pretty much has to be inline. 

    >> some malicious third party? Assuming that the third party does not
    >> drop any packets in the flow, we have: a) additional latency.  b)
    >> traffic analysis.

    Charlie> But any party on the path between the two IPsec endpoints can do
    Charlie> this anyway - with or without invoking NAT-T.

  I agree. 
  I'm wasn't explicit in saying that these aren't unique attacks to NAT-T.

    Charlie> That's not to say that these threats aren't serious. Just that
    Charlie> there is nothing we could possibly do within IKE or ESP to
    Charlie> improve the situation.

  The thing that we could do, is require some kind of three way handshake to
change the UDP port #/IP address. That could be a rekey.

  This assures that the flow doesn't get aimed at some innocent bystandard
until the real client speaks again. 

  The sequence would go something like this:

      gateway receives new UDP port #/IP
#1    sends notify to old UDP port #/IP,
	    indicating that it thinks it should change
#2    sends notify to new UDP port #/IP,
	    indicating that it thinks it is time to rekey

  A client receiving #1 can reply, saying "no thank you" if it doesn't
want to rekey yet.
  A client receiving #2 can reply with a rekey.
  A client receiving both could cancel the rekey with some token from
#1. 
 
  This might all fit into Dead Peer Detection.

  Note that an observer can easily figure out which is IKE traffic and
which is ESP traffic. The truly paranoid may want to have the gateway send
the IKE traffic inside the ESP tunnel. This seems very fragile to me.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 06 Mar 2003 16:58:06 +0100

=> IMHO this is only true for the bidding down attack itself
because for the transient pseudo-NAT attack the initiator/client
won't receive the reply so will retransmit the request.

=> agreed

=> in fact the only useful thing in favor of my bidding down argument
is that NAT-T is less secure.

=> it won't be enough: you just increase the number of messages the
pseudo-NAT attacker has to patch.

   

   
   
=> we (me and Tero) already discussed about this kind of three way
handshakes... in fact they are more useful for mobility/multihoming
(they provide more than the trust in the other peer to own its address).
 About NAT-T, it seems the best defense is to support an implicit
address change, i.e., the peer address is updated in all SAs as soon as
a packet (ESP or IKE) is received from a new address. The transient
pseudo-NAT attack still works but its effect is transient, i.e., the
first unmodified packet from the peer will put again the right address.
And this is more efficient for the NAT-T itself.

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Thu, 06 Mar 2003 16:45:44 +0100

=> I agree: this is why I called the attacker in this context a
pseudo-NAT.

   
   
   What am I missing?
   
=> the attacker can divert a lot of ESP traffic when it modifies only
a very small number of IKE messages. It can, for instance, quit the
path between the two IKE peers as soon as its job is done (this is
why I called it a transient pseudo-NAT).

Thanks

PS: for this part of my "bidding down" argument, we need only to agree
that NAT traversal is less secure than no NAT traversal. Especially we
don't need to find defense against the "transient pseudo-NAT" attack
other than to protect the peer addresses (easy and efficient but
not compatible with NAT traversal).

---

From: Dan Harkins <[email-masked]>
Date: Thu, 06 Mar 2003 11:17:01 -0800

Charlie,

  When we started the IKEv2 effort we wanted to use the lessons learned
from deployment of IKEv1 to decide what to change and how to change it.

  One of the things that almost never happened in a non-lab, non-bakeoff
environment was negotiation of SAs. No one ever really took advantage of
the complex ANDing and ORing of arbitrary proposals. So we did away with
it. I'll return to this in a second but...

  To answer your question, yes I prefer the a la carte method specified
in ikev2-02 more than I prefer the suites _and_ a la carte method
specified in ikev2-05. We should either have suites period or a la carte
period. Having both strikes me as redoing the mistakes from IKEv1 (in
an attempt to get "consensus" I tried to satisfy everyone's demands and
ended up with an overly complex beast that we all have grown to hate).

  You mention that a Diffie-Hellman group is part of the attributes
of SAs negotiated as a suite. Well, not really, as I said in my
original post on this subject. They're not part of the IPsec suites
which makes the supporting a Diffie-Hellman exchange in the 
CREATE_CHILD exchange difficult. Do you guess the group by the length
of the KE payload? That doesn't seem right and if that's the way to do
it then why have the Diffie-Hellman group as part of the IKE suite?
So properly supporting Diffie-Hellman groups in IPsec suites requires
a doubling of the IPsec suites. That is an argument against suites.

  Now back to negotiation. You say we lose the ability to offer different
compression algorithms with different suites. But our deployment experience
would show that such a capability is not necessary because it wouldn't
be used. We just have to allow the each side to say what algorithm they
are willing to do and what CPI they want to do it under (for the reasons
Avram mentioned). Such a la carte "negotiation" is currently supported in
IKEv2-05 but that's because IKEv2-05 mandates BOTH suites and a la carte.

  IKEv2-02 has a whole bunch of vanity algorithms (triple IDEA, IDEA, RC5,
TIGER, etc) that we can do away with. But the method of specifying what
you wanted to do was much simpler and it avoids the suite explosion we're
already seeing. IKEv2-02 also had the complex ANDing and ORing that I
think we should get rid of. Why not just have a single SA payload that
contains TLVs for each of the necessary attributes? Multiple occurances
of an attribute mean "I'll do either" (as it was in IKEv2-02 even though
I doubt that would be used much if ever).

   initiator: "ESP: 3DES, HMAC-SHA, Group 5, LZS, CPI=x" 
   responder: "ESP: 3DES, HMAC-SHA, Group 5". 

There, IPcomp was just un-negotiated. And they agreed on everything else.

  Whether we have suites or a la carte our deployment experience shows
that 99% of the time the initiator will just offer a single suite or
an a la carte offer of one algorithm each. There won't be any "negotiation".
It's just agreement or it's a mis-configuration. 

  Dan.

On Mon, 03 Mar 2003 21:19:36 EST you wrote

---

From: Francis Dupont <[email-masked]>
Date: Thu, 06 Mar 2003 16:58:06 +0100

=> agreed

   

   

   

Thanks

---

From: Derek Atkins <[email-masked]>
Date: 10 Mar 2003 14:08:56 -0500

> I doubt that would be used much if ever).

While I agree with everything else you said about 02 vs 05 (cut from
this reply), I do need to add that the one argument I heard that
implies AND and OR are necessary in an a la carte system is for
hardware deployments that support multiple algorithms but NOT in
arbitrary combinations.  For example, a hardware implementation that
ONLY supports 3DES with MD5, or AES with SHA-1...

Granted, this is probably a rare occurance, but I've heard this
argument from a few people over the years so I have no reason to
ignore it.  In order to support this architecture you need some
mechanism to negotiate pseudo-suites.  It's rare, and obviously in a
software implementation you don't need to worry about it.  However if
we wish to support specialized hardware implementations we do kind of
need this mechanism.

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Paul Koning <[email-masked]>
Date: Mon, 10 Mar 2003 15:55:36 -0500

>>>>> "Derek" == Derek Atkins <[email-masked]> writes:

 Derek> Dan Harkins <[email-masked]> writes:
 >> already seeing. IKEv2-02 also had the complex ANDing and ORing
 >> that I think we should get rid of. Why not just have a single SA
 >> payload that contains TLVs for each of the necessary attributes? 
 >> Multiple occurances of an attribute mean "I'll do either" (as it
 >> was in IKEv2-02 even though I doubt that would be used much if
 >> ever).

 Derek> While I agree with everything else you said about 02 vs 05
 Derek> (cut from this reply), I do need to add that the one argument
 Derek> I heard that implies AND and OR are necessary in an a la carte
 Derek> system is for hardware deployments that support multiple
 Derek> algorithms but NOT in arbitrary combinations.  For example, a
 Derek> hardware implementation that ONLY supports 3DES with MD5, or
 Derek> AES with SHA-1...

 Derek> Granted, this is probably a rare occurance, but I've heard
 Derek> this argument from a few people over the years so I have no
 Derek> reason to ignore it. 

I wonder: is this still a real issue today?   It would be good not to
add messes to the protocol to support strange hardware architectures
that are long obsolete.  Certainly this issue doesn't appear in any
hardware I have ever seen.  (Come to think of it, if I saw this when
doing device selection, I'd be very tempted to exclude such a device.)

      paul

---

From: Eric Rescorla <[email-masked]>
Date: 10 Mar 2003 15:27:29 -0800

Paul Koning <[email-masked]> writes:

> >>>>> "Eric" == Eric Rescorla <[email-masked]> writes:
> 
>  Eric> Paul Koning <[email-masked]> writes:
>  >> I wonder: is this still a real issue today?  It would be good not
>  >> to add messes to the protocol to support strange hardware
>  >> architectures that are long obsolete.  Certainly this issue
>  >> doesn't appear in any hardware I have ever seen.  (Come to think
>  >> of it, if I saw this when doing device selection, I'd be very
>  >> tempted to exclude such a device.)
> 
>  Eric> It's generally not an issue of individual pieces of hardware
>  Eric> but of what happens when you have an implementation based on
>  Eric> multiple CSP-like modules.
> 
>  Eric> Say, for the sake of argument that you have a piece of hardware
>  Eric> that processes single IPsec records and supports 3DES and SHA.
>  Eric> You then add another CSP that supports AES and MD5. You can't
>  Eric> necessarily mix and match here, so you need to provide
>  Eric> profiles.
> 
> Sure, you can suppose such things, but are they real? That's my
> point.  I can't think of real hardware that matches your supposition.
What, you can't think of real hardware that doesn't support AES?
How about the HiFn 7811?
    
-Ekr

-- 
[Eric Rescorla                                   [email-masked]]
                http://www.rtfm.com/

---

From: Eric Rescorla <[email-masked]>
Date: 10 Mar 2003 15:13:08 -0800

> doing device selection, I'd be very tempted to exclude such a device.)

It's generally not an issue of individual pieces of hardware but
of what happens when you have an implementation based on
multiple CSP-like modules.

Say, for the sake of argument that you have a piece of hardware
that processes single IPsec records and supports 3DES and SHA.
You then add another CSP that supports AES and MD5. You can't
necessarily mix and match here, so you need to provide profiles.

-Ekr

---

From: Paul Koning <[email-masked]>
Date: Mon, 10 Mar 2003 18:18:23 -0500

paul

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Mon, 10 Mar 2003 14:11:19 -0800

>ONLY supports 3DES with MD5, or AES with SHA-1...

One of the early goals for IKEv2 was simplicity. Doing AND and OR 
moves sharply away from that. Dan's proposal above would be much 
simpler to implement.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Scott G. Kelly" <[email-masked]>
Date: Mon, 10 Mar 2003 15:56:50 -0800

I agree with Paul - I've evaluated and used a number of crypto
processors in the last few years, and I don't think any of them had this
limitation, and I think Paul is  right that spec'ing around such
behavior is probably not required (or a good idea).

Scott

---

From: Derek Atkins <[email-masked]>
Date: 10 Mar 2003 21:21:44 -0500

> moves sharply away from that. Dan's proposal above would be much

That's fine.  I have no specific, personal objection to leaving out
the AND and OR functionality.  I was just pointing out that there
were reasonable reasons to have such functionality.

If we DO decide to leave it out in the name of simplicity we should at
least add some text that shows that we thought about this issue.  I
would propose something like:

  Certain hardware architectural implementations may only support
  limited combinations of algorithms.  For example, a piece of
  hardware may only support 3DES+MD5 or AES+SHA1, but there is no way
  to actually negotiate for one or the other combinations.  The
  working group acknowledges this limitation, but decided in favor of
  the simplicity of ruling out such architectures.

-derek

---

From: Paul Koning <[email-masked]>
Date: Tue, 11 Mar 2003 08:37:46 -0500

Eric> Paul Koning <[email-masked]> writes:
 >> >> I wonder: is this still a real issue today?  It would be good
 >> not >> to add messes to the protocol to support strange hardware
 >> >> architectures that are long obsolete.  Certainly this issue >>
 >> point.  I can't think of real hardware that matches your
 Eric> What, you can't think of real hardware that doesn't support
 Eric> AES?  How about the HiFn 7811?

Sure I know about that hardware, but that wasn't your example.  You
said "3DES and SHA" vs. "AES and MD5".  7811 supports 3DES with either
SHA or MD5; later chips support AES with either SHA or MD5.  So the
choice for authentication function does not affect whether you are
able to perform a given encryption algorithm.

     paul

---

From: Eric Rescorla <[email-masked]>
Date: 11 Mar 2003 07:33:34 -0800

> able to perform a given encryption algorithm.
I don't know of any real hardware that supports the second combination,
but I wouldn't be at all surprised to hear about it. 

I haven't examined this particular IPsec situation in excruciating
detail but I can tell you that this kind of thing used to come up all
the time with SSL, especially when the private keying material is also
in hardware for security purposes.  So, for instance, you couldn't mix
and match Skipjack with DH. And the more individual negotiable items
one has, the worse things get. For instance, if one ends up
negotiating compression as well..

However, if none of the hardware guys care, I suppose that one can
consider this a theoretical issue.

-Ekr

---

From: Tylor Allison <[email-masked]>
Date: Wed, 12 Mar 2003 07:22:01 -0600 (CST)

> were reasonable reasons to have such functionality.

I agree with this approach as well...

>   the simplicity of ruling out such architectures.

Or perhaps add text which states that the limitation exists, and is up to
such implementation to work within the rules of the protocol.  Such a
device can still interoperate, it will just be harder for the
implementation.  For example, they can attempt to negotiate an AES+SHA1 SA
first... failing that, attempt a new SA negotiation for 3DES+MD5.  Granted,
this is not pretty, but neither is the hardware implementation that they
are trying to support.

> -derek

=====================================================================
= Tylor Allison         Secure Computing Corporation        =========
=====================================================================

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 11 Mar 2003 21:53:41 +0200 (EET)

> You then add another CSP that supports AES and MD5. You can't

Then the IKE must select one of those and offer only that. If the
negotiation fails it can try the other. As told earlier in this thread
most of the IPsec initiators are configured to only send one offer
anyways, so I don't really think this is very big issue. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/