Subject: [anonsec] Channel Bindings

From: Black_David at emc.com ([email-masked])
Date: Fri Nov 19 12:52:25 2004

I thought I'd back up a little bit and try to explain what
channel bindings are about.

Consider a protocol such as iSCSI (runs over TCP) that does
useful/real authentication (i.e., something significantly
better than "password in the clear"), but uses IPsec to
provide cryptographic integrity and confidentiality rather
than doing either itself.

The goal of channel bindings for such a protocol is to:
- Only authenticate once at the iSCSI level.  This simplifies
	management by eliminating IPsec level identities and
	associated management of credentials/secrets/etc.  IPsec
	sets up SAs anonymously (promiscuously if you like).
- Detect and stop man-in-the-middle attacks before they do
	any "real" damage, where "real" is defined at the iSCSI
	level.
There no free lunch principle applies here - because there are
no IPsec identities, IPsec can't stop a man-in-the-middle at
the IPsec level.  The SAs will be created, but a channel binding
allows the higher level protocol to detect that a man-in-the-
middle event has happened and tear the connection down afterwards
before anything useful has happened at the higher level.

Here's one way that it could work, with Alice, Bob and Mallory
(the proverbial "man-in-the-middle"):

Alice <--- SA 1 ---> Mallory <--- SA 2 ---> Bob

Mallory gets in the middle of the IKE exchange and because there
are no identities, he has no problem impersonating Alice and Bob
to each other.  The result is two different SAs as shown above
with Mallory in the middle, even though Alice and Bob think
they're talking to each other.  This is a problem ...

The solution starts by observing that while Mallory can get in
the middle of IKE, he can't force the two SAs to have the same
DH exchange, and hence the DH secrets for SA 1 and SA 2 will be
different.  If Alice now authenticates to Bob in a fashion that
depends on the DH secret for SA 1, the authentication will fail
because Bob will check the DH secret for SA 2 and it won't match.
Note that just passing the DH secret on the connection isn't
enough because Mallory can make the obvious substitution - the
DH secret has to be folded into an authentication algorithm
that isn't "password in the clear".

For iSCSI the most common authentication algorithm is a strengthened
version of CHAP (see RFC 3720).  CHAP sends a challenge that is hashed
with a shared secret to produce a response.  If this hash is extended
to include the DH secret from the IPsec SA to the CHAP hash, Mallory
loses, because:
	- Mallory couldn't force the DH secrets to be the same on
		SA 1 and SA 2, so passing Alice's response through
		doesn't work.
	- Mallory doesn't know Alice's CHAP secret, so he can't
		generate the correct response.
Hence Alice fails to authenticate to Bob, and this failure occurs
before anything useful happens at the iSCSI level.  This scenario
is applicable to all of the IP Storage protocols, as in addition
to iSCSI, T11 is defining strong authentication for Fibre Channel
(for iFCP and FCIP), and it's also applicable to NFSv4.

I have a couple of observations beyond here:

(1) The above scenario can be turned into a denial of service
	attack on IPsec via creation of lots of SAs that have to
	be subsequently torn down.

This is correct, and it's a "no free lunch" result.  To a first
approximation, the price of resisting this sort of DoS attack
is doing authentication and hence identity management for IPsec.
Anything we do that involves anonymous setup of IPsec is going
to be open to this class of denial of service attack.

(2) The binding is to the SA itself, not to something that may
	outlive the SA.

The binding is sufficient to get the job done.  iSCSI supports
reauthentication if the SA gets replaced, or it may be possible to
bind to the phase 1 SA, which should live for much longer.  While
binding to a public key identity (e.g., self-signed certificate)
that outlives the phase 1 SA might be better in principle, I'm
not sure that it makes an enormous difference in practice.

I hope this is useful.

Thanks,
--David

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: kent at bbn.com (Stephen Kent)
Date: Fri Nov 19 15:37:19 2004

David,

You provided a good description of what you would like from an 
unauthenticated IPsec SA, and the importance of binding it to higher 
level authentication info, to detect and reject a MITM attack. 
However, there may be a problem with doing what you want. 
Specfcifically, exporting bits from the DH exchange to a higher layer 
might conflict with the FIPS 140-2 requirements for key protection, 
requirements that one would like to see in a crypto module supporting 
IPsec. It would depend on how the bits are exported, what sort of 
functions the module provided at its interface, and how CHAP was 
implemented.

For example, if you had a chip that did basic crypto functions that 
support IPsec and TLS, then it probably would not be able to export 
DH bits to software like CHAP for combining with the application 
layer auth data, without violating 140-2. one would have to get CHAP 
to make use of the chip, and the chip would have to embody the 
function to take the DH bits and the higher layer secret and combine 
them and generate the hash, which was then handed back to CHAP for 
transmission.

I'm not saying one can't figure out a way to do this and still have 
an evaluated crypto module, but it will require some care and maybe 
changes to existing modules.

Steve

---

From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC)
Date: Fri Nov 19 17:26:19 2004

At 6:34 PM -0500 11/19/04, Stephen Kent wrote:
>Specfcifically, exporting bits from the DH exchange to a higher 
>layer might conflict with the FIPS 140-2 requirements for key 
>protection, requirements that one would like to see in a crypto 
>module supporting IPsec. It would depend on how the bits are 
>exported, what sort of functions the module provided at its 
>interface, and how CHAP was implemented.

That would only be true for bits from the DH secret. If I understand 
channel binding correctly, you woudn't need to export the secret, 
only the publics that were passed in messages 3 and 4 (in IKEv1). 
That is, the iSCSI (or whatever) authentication could mix in those 
publics with the protocol-specific auth to be sure that the SA 
established was between Alice and Bob without Mallory. "I used these 
two things to get my DH secret" is enough.

--Paul Hoffman, Director
--VPN Consortium

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri Nov 19 21:22:52 2004

> changes to existing modules.

Agreed.

You might remember some posts from me to the IPsec list asking about a
way to generate channel bindings for an SA and suggesting a new SK_
value to be taken from the prf+(SKEYSEED, ...).  This amounts to one way
to do what Paul would have us do without, perhaps, conflicting with
FIPS-140-2, BUT (and I mention all this as a preemtive measure), we'd
then be back to issues such as:

    Do we use the IKE_SA, or CHILD_SAs for the binding?  If if we're to
    use the CHILD_SAs, well, that means having a KE for each
    unauthenticated CHILD_SA pair, not just for the IKE_SA.  And
    CHILD_SAs come in pairs, so we'd have to combine the two bindings
    (not hard).  And what if there's more than one live SA pair for the
    given TSs at the time?  And what if an SA expires in the middle of a
    TCP connection handshake, how would one complete the requisite
    "connection latching?"  (Failure might be an option, but if we can
    do better -- and you know I think we can -- then we should.)  And,
    since all the foregoing is quite IKEv2-specific, how would one make
    this work with IKEv1?  And what of future KE protocols, as MOBIKE
    threatened?

I was a proponent of the non-cert approach to unathenticated IPsec
first, and now I've changed this view.  Bill brought these issues to my
attention, and soon I found them devastating.  Using asserted IDs as
channel bindings and cert public keys as IDs we can solve the problem in
a way that is robust and yet also not really specific to IKEv2 either.

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Mon Nov 22 08:22:37 2004

>two things to get my DH secret" is enough.

I was assuming from David's text that he wanted to use bits from the 
output of the PRF that we employ in IKE to mix with the higher level 
authentication secret to bind the channel.  Let's ask David what he 
had in mind.

Steve