[anonsec] details of IKE/IPsec channel binding

[Michael Richardson]

At lunch I was discussing the question of what the IKE/IPsec channel binding blog would be.

(Nico, did we really miss refreshing draft-ietf-btns-connection-latching-00.txt
before it expired? okay... http://www.sandelman.ca/SSW/ietf/ipsec/btns/connection-latching-00.txt
if someone needs a copy)

oops, anyway, I want to refer to: draft-williams-on-channel-binding-01.txt, section 4.2
suggests to use the host keys.

at lunch, I said that this kept making me queezy to have the channel binding only
be what amount to be public information. I discovered that my queeziness was because
I forgot that the application doing the channel binding itself was going to communicate
the channel binding blog via an integral channel.

I had previously thought that the channel binding was going to be some *secret*,
which had to be communicated carefully or, at least had to have built-in
integrity. This is wrong, the application is responsible for that. A GSSAPI
application would already have a secure channel in which to put the channel
binding.

The question is, do we still need to have something as a channel binding that
has a stronger binding to the Diffie-Hellman.

My thought was to generate another key from SKEYSEED, and do:
HMAC-prf(K, concatenation-of-public-keys);
and send that as well.
This would mean that comparing channel binding blogs is not just a memcpy(),
but now involves getting the key (K), and checking the hash.

Thoughts?

This has API impacts, if we have to provide for checking a channel
blog, not just communicating it to the applications for memcpy() check.

[Francis Dupont]

In your previous mail you wrote:

My thought was to generate another key from SKEYSEED, and do:
HMAC-prf(K, concatenation-of-public-keys);
and send that as well.
This would mean that comparing channel binding blogs is not just a memcpy(),
but now involves getting the key (K), and checking the hash.

Thoughts?

=> what about to use the INTEG (integrity algorithm) in place of
the PRF (pseudo-random function) with the same arguments?
(IMHO this is more appropriate to the intended usage.)

Regards

Francis.Dupont at fdupont.fr

[Michael Richardson]

>>>>> "Francis" == Francis Dupont <Francis.Dupont at fdupont.fr> writes:
Francis> => what about to use the INTEG (integrity algorithm) in
Francis> place of the PRF (pseudo-random function) with the same
Francis> arguments? (IMHO this is more appropriate to the intended
Francis> usage.)

If I understand you, that's a phase 2/CHILD-SA thing that is
negotiated, and perhaps not every phase 2 has an integrity algorithm.
It might also be that the negotiated phase 2 algorithm is only
implemented/available in a line card the implements the phase 2, and has
no software implementation in the "host".
(Consider some kind of patented algorithm)

- --
] Bear: "Me, I'm just the shape of a bear." | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr at xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

[Nicolas Williams]

On Wed, Mar 21, 2007 at 05:46:03PM +0100, Michael Richardson wrote:
> At lunch I was discussing the question of what the IKE/IPsec channel binding blog would be.

I think you meant "blob" not "blog" :)

We've discussed this before and the answer is:

- the public key values of the two peers concatenated in this order:
channel initiator || channel acceptor

or some similar transformation of those two values.

The connection latching I-D doesn't state this, but _could_ state this.
I'd expected to put this into a separate document.

Nico
--

[Julien Laganier]

On Wednesday 21 March 2007 18:06, Nicolas Williams
wrote:
> On Wed, Mar 21, 2007 at 05:46:03PM +0100, Michael
Richardson wrote:
> > At lunch I was discussing the question of what the
> > IKE/IPsec channel binding blog would be.
>
> I think you meant "blob" not "blog" :)
>
> We've discussed this before and the answer is:
>
> - the public key values of the two peers
> concatenated in this order: channel initiator ||
> channel acceptor
>
> or some similar transformation of those two values.

You might also want to do something similar to what HIP
does:

min(pk_i, pk_r) || max(pk_i, pk_r) so that the channel
bindings between two peers is independent from who
initiated the IKE exchange.

--julien

[Michael Richardson]

>>>>> "Julien" == Julien Laganier <julien.IETF at laposte.net> writes:
Julien> You might also want to do something similar to what HIP
Julien> does:

Julien> min(pk_i, pk_r) || max(pk_i, pk_r) so that the channel
Julien> bindings between two peers is independent from who initiated
Julien> the IKE exchange.

I agree that perhaps this makes more sense.
I was going to propose ordering by ordered IP addresses, but this is
perhaps more cool.

- --
] Bear: "Me, I'm just the shape of a bear." | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr at xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

[Nicolas Williams]

On Tue, Apr 03, 2007 at 10:39:46AM -0400, Michael Richardson wrote:
> I was going to propose ordering by ordered IP addresses, but this is
> perhaps more cool.

I don't believe that you'd think of ordering by IP addresses when you're
also so concerned about support for NAT! ;)

[Michael Richardson]

>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
>> I was going to propose ordering by ordered IP addresses, but this
>> is perhaps more cool.

Nicolas> I don't believe that you'd think of ordering by IP
Nicolas> addresses when you're also so concerned about support for
Nicolas> NAT! ;)

Yes, that's why I prefer the min/max construct.

- --
] Bear: "Me, I'm just the shape of a bear." | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr at xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

[Nicolas Williams]

On Tue, Apr 03, 2007 at 03:26:42PM +0200, Julien Laganier wrote:
> You might also want to do something similar to what HIP
> does:
>
> min(pk_i, pk_r) || max(pk_i, pk_r) so that the channel
> bindings between two peers is independent from who
> initiated the IKE exchange.

We've long known we'd have to do something like that because
initiator/responder at the IKE layer can be the opposite of
client/server roles at the ULP or higher layers. (TCP-like protocols
can always figure out which is which and put the two public keys in
client || server order.

[Nicolas Williams]

On Wed, Mar 21, 2007 at 05:46:03PM +0100, Michael Richardson wrote:
> at lunch, I said that this kept making me queezy to have the channel binding only
> be what amount to be public information. I discovered that my queeziness was because
> I forgot that the application doing the channel binding itself was going to communicate
> the channel binding blog via an integral channel.

Exactly.

> I had previously thought that the channel binding was going to be some *secret*,
> which had to be communicated carefully or, at least had to have built-in
> integrity. This is wrong, the application is responsible for that. A GSSAPI
> application would already have a secure channel in which to put the channel
> binding.

Exactly.

> The question is, do we still need to have something as a channel binding that
> has a stronger binding to the Diffie-Hellman.

No. It suffices that we have the keys used to "authenticate" the peers
in IKE (when using BTNS we're not really authenticating them, but we
still have such keys). This applies only when using traditional
PKI-based IKE, not when using EAP.

> My thought was to generate another key from SKEYSEED, and do:

No can do. (Originally I'd proposed something just like that.) The
reason is, as explained to me by Bill Sommerfeld right before my first
presentation on this topic back at, IIRC, IETF59:

- Imagine I send a SYN packet protected with some SA, say, SPI 1001,
but the SYN|ACK does not arrive in time so I retransmit, only this
time I use a new SA (SPI 1002, say) because, say, the old one
expired.

We can get into a weird situation: the SA that _I_ see as the one
used to protect the channel creation trigger is _different_ from the
one seen by my peer, so we fail to agree on channel binding!

This is how I came to add the notion of "end-point channel bindings" vs.
"unique channel bindings."

Nico
--

[Tero Kivinen]

Nicolas Williams writes:
> - Imagine I send a SYN packet protected with some SA, say, SPI 1001,
> but the SYN|ACK does not arrive in time so I retransmit, only this
> time I use a new SA (SPI 1002, say) because, say, the old one
> expired.
>
> We can get into a weird situation: the SA that _I_ see as the one
> used to protect the channel creation trigger is _different_ from the
> one seen by my peer, so we fail to agree on channel binding!
>
> This is how I came to add the notion of "end-point channel bindings" vs.
> "unique channel bindings."

As the first SPI 1001 already creted the IKE SA and generated the
SKEYSEED, even if you crete new IPsec SA (using the same IKE SA, I
assume) the value generated from the SKEYSEED stays same (it is tied
to IKE SA not to the IPsec SAs). I assume we are only talking about
IKEv2 here, as there is no point of doing any work on the obsoleted
protocols.

If you really destroyed the IKEv2 SA also between those two packets
then you would be seeing different value, but on the other hand same
happens, if you happen to recreate new private / public key pair
between those exchanges (and as IKEv2 SA will probably be there for
several minutes in any case, the only reason to tear it down quickly
is the change of the authentication information, like private /
public key pair, so that thing happening is not that uncommon when
comparing to first case).

Anyways you always need to take care of the case where some packet can
have two different channels bound to it, for example if some fragments
of the final packet arrived through the IPsec SA authenticated using
public key X of IKEv2 SA 1, and other parts came from IPsec SA using
public key Y of IKEv2 SA 2. This can happen if you use the
fragmentation handling from the rfc4301 where you put non-first
fragments to one SA (which might be created using the host public /
private key pair X) and first fragments are put to the port specific
IPsec SA which is created using users public / private key pair Y.

So there we are not talking about two different packets having
different channel binding values, we are talking of different parts of
the one packet having different channel bindings.
--
kivinen at safenet-inc.com

[Nicolas Williams]

On Wed, Mar 21, 2007 at 08:52:09PM +0200, Tero Kivinen wrote:
> Nicolas Williams writes:
> > - Imagine I send a SYN packet protected with some SA, say, SPI 1001,
> > but the SYN|ACK does not arrive in time so I retransmit, only this
> > time I use a new SA (SPI 1002, say) because, say, the old one
> > expired.
> >
> > We can get into a weird situation: the SA that _I_ see as the one
> > used to protect the channel creation trigger is _different_ from the
> > one seen by my peer, so we fail to agree on channel binding!
> >
> > This is how I came to add the notion of "end-point channel bindings" vs.
> > "unique channel bindings."
>
> As the first SPI 1001 already creted the IKE SA and generated the
> SKEYSEED, even if you crete new IPsec SA (using the same IKE SA, I
> assume) the value generated from the SKEYSEED stays same (it is tied
> to IKE SA not to the IPsec SAs). I assume we are only talking about
> IKEv2 here, as there is no point of doing any work on the obsoleted
> protocols.

This needs to work for IKEv1. Assuming that the IKE_SA is still around
is not a good assumption.

Besides, the used of the public key values of the two peers as the
channel binding suffices.

Nico
--

[Michael Richardson]

>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
Nicolas> This needs to work for IKEv1. Assuming that the IKE_SA is
Nicolas> still around is not a good assumption.

I have no problem with requiring that the IKE_SA remain around.
Seriously.

- --
] Bear: "Me, I'm just the shape of a bear." | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr at xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

[Nicolas Williams]

On Sun, Apr 01, 2007 at 05:44:30PM -0400, Michael Richardson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
> Nicolas> This needs to work for IKEv1. Assuming that the IKE_SA is
> Nicolas> still around is not a good assumption.
>
> I have no problem with requiring that the IKE_SA remain around.
> Seriously.

The channel initiator (client) can certainly keep it around. The
server need not have any idea that it will have to keep it around.

What we could do is make the connect() fail if the client were to
retransmit a TCP SYN (or whatever) protected by a child SA of a
different IKE_SA even though for the same peer.

But how do you make that work for connect()ed UDP sockets? Or perhaps
we should say that connect()ed UDP sockets don't have channel bindings,
use IPsec APIs instead of connected UDP socets. I'd be willing to live
with that.

Nico
--

[Nicolas Williams]

On Sun, Apr 01, 2007 at 05:35:34PM -0500, Nicolas Williams wrote:
> On Sun, Apr 01, 2007 at 05:44:30PM -0400, Michael Richardson wrote:
> > >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
> > Nicolas> This needs to work for IKEv1. Assuming that the IKE_SA is
> > Nicolas> still around is not a good assumption.
> >
> > I have no problem with requiring that the IKE_SA remain around.
> > Seriously.
>
> The channel initiator (client) can certainly keep it around. The
> server need not have any idea that it will have to keep it around.

Responding to myself: i.e., what if the server reboots or otherwise
loses IKE state?

Nico
--

[Nicolas Williams]

On Wed, Mar 21, 2007 at 02:41:11PM -0700, Charlie Kaufman wrote:
> As you both note, the channel bindings need not be secret. In fact,
> life is much simpler if they are not.
>
> Basing the channel bindings on the public keys of the two endpoints is
> secure *if* the two endpoints keep their private keys private (by
> either generating them randomly on each run of the protocol and
> promptly forgetting them or storing them in a safe place). This will
> be true most of the time, so perhaps it's no great sacrifice to demand
> it be true all the time. My biggest concern is that it doesn't work
> with shared secret or EAP authentication.
>
> As Nicolas notes, there is a possible problem with winding in any of
> the current session keys because the exchange could fail if it takes
> place in the middle of a session key rollover. That's sufficiently
> unlikely that one could choose to live with it, but it sure is ugly.
>
> The way I wish I had specified it in the original IKEv2 spec was that
> channel bindings would be additional bytes taken from the key
> expansion using PRF+ of SKEYSEED of the original IKE SA (i.e., it
> would not change even if the IKE SA were rekeyed and all of the IPsec
> SAs were rekeyed). This would be a good solution, but might be tricky
> to implement depending on how your IPsec implementation is structured.

Again, this has to work with IKEv1. Bill so insisted, and I agree.

We could use this approach when using IKEv2 so it also works when using
EAP, and fallback on public keys when IKEv1 is being used, and oh well
if you ever get bitten by the problem I described.

Nico
--

[Tero Kivinen]

Nicolas Williams writes:
> Again, this has to work with IKEv1. Bill so insisted, and I agree.

Hmm... the BTNS charter only talks about "Current Internet Protocol
security protocol (IPsec) and Internet Key Exchange protocol (IKE)",
it does not mention IKEv1 anywhere.

The current IPsec and IKE is the RFC430x series, i.e. IKEv2. The old
RFC240x series is obsoleted.

Also the BTNS charter talks about RFC4301 / RFC4306 (IKEv2) concepts
like PAD, and bare RSA keys.

> We could use this approach when using IKEv2 so it also works when using
> EAP, and fallback on public keys when IKEv1 is being used, and oh well
> if you ever get bitten by the problem I described.

I argue should we waste time at all to define anything else than the
RFC4301 and IKEv2 use. Things were different few years back when this
work was started...
--
kivinen at safenet-inc.com

[Nicolas Williams]

On Thu, Mar 22, 2007 at 12:12:21PM +0200, Tero Kivinen wrote:
> Nicolas Williams writes:
> > Again, this has to work with IKEv1. Bill so insisted, and I agree.
>
> Hmm... the BTNS charter only talks about "Current Internet Protocol
> security protocol (IPsec) and Internet Key Exchange protocol (IKE)",
> it does not mention IKEv1 anywhere.
>
> The current IPsec and IKE is the RFC430x series, i.e. IKEv2. The old
> RFC240x series is obsoleted.

IKEv1 is certainly not obsoleted. And RFC4301 does support IKEv1, does
it not?

> > We could use this approach when using IKEv2 so it also works when using
> > EAP, and fallback on public keys when IKEv1 is being used, and oh well
> > if you ever get bitten by the problem I described.
>
> I argue should we waste time at all to define anything else than the
> RFC4301 and IKEv2 use. Things were different few years back when this
> work was started...

First I'd like to be convinced that the IKE_SA expiration in the middle
of channel setup is no big deal. That is, I'd like to see consensus on
this. And I'd like input from our AD about whether we need to support
IKEv1.

Nico
--

[Tero Kivinen]

Nicolas Williams writes:
> IKEv1 is certainly not obsoleted.

All obsoleted:

2401 Security Architecture for the Internet Protocol. S. Kent, R.
Atkinson. November 1998. (Format: TXT=168162 bytes) (Obsoletes
RFC1825) (Obsoleted by RFC4301) (Updated by RFC3168) (Status:
PROPOSED STANDARD)

2402 IP Authentication Header. S. Kent, R. Atkinson. November 1998.
(Format: TXT=52831 bytes) (Obsoletes RFC1826) (Obsoleted by
RFC4302,
RFC4305) (Status: PROPOSED STANDARD)

2406 IP Encapsulating Security Payload (ESP). S. Kent, R. Atkinson.
November 1998. (Format: TXT=54202 bytes) (Obsoletes RFC1827)
(Obsoleted by RFC4303, RFC4305) (Status: PROPOSED STANDARD)

2407 The Internet IP Security Domain of Interpretation for ISAKMP. D.
Piper. November 1998. (Format: TXT=67878 bytes) (Obsoleted by
RFC4306) (Status: PROPOSED STANDARD)

2408 Internet Security Association and Key Management Protocol
(ISAKMP). D. Maughan, M. Schertler, M. Schneider, J. Turner. November
1998. (Format: TXT=209175 bytes) (Obsoleted by RFC4306) (Status:
PROPOSED STANDARD)

2409 The Internet Key Exchange (IKE). D. Harkins, D. Carrel. November
1998. (Format: TXT=94949 bytes) (Obsoleted by RFC4306) (Updated by
RFC4109) (Status: PROPOSED STANDARD)

> And RFC4301 does support IKEv1, does
> it not?

>From RFC4301:

Note: This document mandates support for several features for which
support is available in IKEv2 but not in IKEv1, e.g., negotiation of
an SA representing ranges of local and remote ports or negotiation of
multiple SAs with the same selectors. Therefore, this document
assumes use of IKEv2 or a key and security association management
system with comparable features.

> First I'd like to be convinced that the IKE_SA expiration in the middle
> of channel setup is no big deal. That is, I'd like to see consensus on
> this.

I need to think about this more before making my mind for this. My
initial feeling do say that we should bind it to the IKE
authentication, i.e. the to the Diffie-Hellman exchange.

> And I'd like input from our AD about whether we need to support
> IKEv1.

Me too...
--
kivinen at safenet-inc.com

[Stephen Kent]

At 6:47 AM -0500 3/22/07, Nicolas Williams wrote:
>On Thu, Mar 22, 2007 at 12:12:21PM +0200, Tero Kivinen wrote:
>> Nicolas Williams writes:
>> > Again, this has to work with IKEv1. Bill so insisted, and I agree.
>>
>> Hmm... the BTNS charter only talks about "Current Internet Protocol
>> security protocol (IPsec) and Internet Key Exchange protocol (IKE)",
>> it does not mention IKEv1 anywhere.
>>
>> The current IPsec and IKE is the RFC430x series, i.e. IKEv2. The old
>> RFC240x series is obsoleted.
>
>IKEv1 is certainly not obsoleted. And RFC4301 does support IKEv1, does
>it not?

4301 includes mandatory features that IKEv1 cannot negotiate, so in
that sense 4301 assumes use of IKEv2.


Steve

[Nicolas Williams]

On Thu, Mar 22, 2007 at 09:38:39AM -0400, Stephen Kent wrote:
> >IKEv1 is certainly not obsoleted. And RFC4301 does support IKEv1, does
> >it not?
>
> 4301 includes mandatory features that IKEv1 cannot negotiate, so in
> that sense 4301 assumes use of IKEv2.

But if we can write connection latching and channel binding specs in a
sufficiently neutral way that IKEv1/RFC2401 can be used, wouldn't that
be good? I did try to write the connection latching I-D that way.

Nico
--

[Michael Richardson]

>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
Nicolas> - Imagine I send a SYN packet protected with some SA, say,
Nicolas> SPI 1001, but the SYN|ACK does not arrive in time so I
Nicolas> retransmit, only this time I use a new SA (SPI 1002, say)
Nicolas> because, say, the old one expired.

Nicolas> We can get into a weird situation: the SA that _I_ see
Nicolas> as the one used to protect the channel creation trigger is
Nicolas> _different_ from the one seen by my peer, so we fail to
Nicolas> agree on channel binding!

Perhaps, in this case, it should fail.

- --
] Bear: "Me, I'm just the shape of a bear." | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr at xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

[Nicolas Williams]

On Sun, Apr 01, 2007 at 05:43:05PM -0400, Michael Richardson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
> Nicolas> - Imagine I send a SYN packet protected with some SA, say,
> Nicolas> SPI 1001, but the SYN|ACK does not arrive in time so I
> Nicolas> retransmit, only this time I use a new SA (SPI 1002, say)
> Nicolas> because, say, the old one expired.
>
> Nicolas> We can get into a weird situation: the SA that _I_ see
> Nicolas> as the one used to protect the channel creation trigger is
> Nicolas> _different_ from the one seen by my peer, so we fail to
> Nicolas> agree on channel binding!
>
> Perhaps, in this case, it should fail.

Well, it will fail. But with the other channel binding scheme it will
succeed, as it should.

We seem to be willing to accept this pathological condition. The only
question is: why not go with the way that doesn't have this corner case?

Possible reasons to reject public-keys-of-peers-as-channel-bindings:

- doesn't work for IKEv2 w/ EAP authentication

But does anyone want to do channel binding to channels where the
peers were authenticated with EAP?

I had a hallway conversation with Sam and Jeff H. about this but I
came away unconvinced: the peers would have to be the client and the
SG (since IKEv2 w/ EAP is only applicable to network access through
IPsec VPNs), so given strong authentication to/of the SG at the IPsec
layer why should any application on the client want to use channel
bindings? Perhaps the EAP method used wasn't very strong -- but then
why use it at all?

Still, I'm certainly open to arguments on this.


- unique channel bindings are better

They certainly are. In SASL WG we saw a presentation about a
password-based challenge/response authentication mechanism (YAP) that
uses unique channel bindings as the server challenge and client
nonce, thus saving a full round-trip (and since it only runs inside a
secure channel it also provides a measure of privacy protection).

So count me as half-convinced.

Nico
--

[Julien Laganier]

On Monday 02 April 2007 00:31, Nicolas Williams wrote:
> On Sun, Apr 01, 2007 at 05:43:05PM -0400, Michael
Richardson wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > >>>>> "Nicolas" == Nicolas Williams
> > >>>>> <Nicolas.Williams at sun.com> writes:
> >
> > Nicolas> - Imagine I send a SYN packet
> > protected with some SA, say, Nicolas> SPI 1001,
> > but the SYN|ACK does not arrive in time so I
> > Nicolas> retransmit, only this time I use a new SA
> > (SPI 1002, say) Nicolas> because, say, the old one
> > expired.
> >
> > Nicolas> We can get into a weird situation:
> > the SA that _I_ see Nicolas> as the one used to
> > protect the channel creation trigger is Nicolas>
> > _different_ from the one seen by my peer, so we
> > fail to Nicolas> agree on channel binding!
> >
> > Perhaps, in this case, it should fail.
>
> Well, it will fail. But with the other channel
> binding scheme it will succeed, as it should.
>
> We seem to be willing to accept this pathological
> condition. The only question is: why not go with
> the way that doesn't have this corner case?
>
> Possible reasons to reject
> public-keys-of-peers-as-channel-bindings:
>
> - doesn't work for IKEv2 w/ EAP authentication

When IKEv2 is used with EAP authentication, the channel
binding blob could fallback from being peers' public
keys to a PRF of the EAP MSK. Both peers know that EAP
was used, so that doesn't even require additional
signalling to let peers generate the appropriate blob.

--julien

[Michael Richardson]

>>>>> "Julien" == Julien Laganier <julien.IETF at laposte.net> writes:
>> We seem to be willing to accept this pathological condition. The
>> only question is: why not go with the way that doesn't have this
>> corner case?
>>
>> Possible reasons to reject
>> public-keys-of-peers-as-channel-bindings:
>>
>> - doesn't work for IKEv2 w/ EAP authentication

Julien> When IKEv2 is used with EAP authentication, the channel
Julien> binding blob could fallback from being peers' public keys to
Julien> a PRF of the EAP MSK. Both peers know that EAP was used, so
Julien> that doesn't even require additional signalling to let peers
Julien> generate the appropriate blob.

This suffers from all the problems that using something derived from
the DH SKEYSEED has. I don't see a *BTNS* case for doing EAP and then
using channel binding, but I might be wrong.

(I can see BTNS for PARENT_SA "authentication", and then EAP for
further authentication of the SA, but at which point, it might be
unnecessary to actually do a channel binding. That's is in theory, but
perhaps in practice, there isn't the total awareness necessary to avoid
this.)

I raised this question, because I felt that it needed to be resolved
in some way, or resolved that we are comfortable with what we had
already. The above proposal has the advantage that, like the
concatenated public keys, it can be checked with memcmp().

This is the fundamental API issue. Is the API:

#1 memcpy suffices:

u_char *my_channel_binding_blob;
int my_channel_binding_blob_len;

u_char *his_channel_binding_blob;
int his_channel_binding_blob_len;

ipsec_get_iToken_attr(iToken, CHANNEL_BINDING,
&my_channel_binding_blob,
&my_channel_binding_blob_len);

gssapi_somefoo_send_channel_binding(my_channel_binding_blob,
my_channel_binding_blob_len);
/* do I look like I know anything about gssapi? */

gssapi_somefoo_recv_channel_binding(&his_channel_binding_blob,
&his_channel_binding_blob_len);

if(my_channel_binding_blob_len == his_channel_binding_blob_len &&
memcmp(my_channel_binding_blob, his_channel_binding_blob,
his_channel_binding_blob_len)==0))
{
return TRUE;
} else {
printf("Mallor has been seen!\n");
return FALSE;
}


#2 channel binding needs to be checked:

u_char *my_channel_binding_blob;
int my_channel_binding_blob_len;

u_char *his_channel_binding_blob;
int his_channel_binding_blob_len;

ipsec_get_iToken_attr(iToken, CHANNEL_BINDING,
&my_channel_binding_blob,
&my_channel_binding_blob_len);

gssapi_somefoo_send_channel_binding(my_channel_binding_blob,
my_channel_binding_blob_len);
/* do I look like I know anything about gssapi? */

gssapi_somefoo_recv_channel_binding(&his_channel_binding_blob,
&his_channel_binding_blob_len);

if(ipsec_check_channel_binding(my_channel_binding_blob,
my_channel_binding_blob_len,
his_channel_binding_blob,
his_channel_binding_blob_len) {
{
return TRUE;
} else {
printf("Mallor has been seen!\n");
return FALSE;
}


Obviously, case #1 can be implemented inside of case #2.
Case #2 may, however, involve a round trip through the kernel to talk to
the keying deamon if the channel binding blob can not be fully
authenticated without key material that the keying daemon prefers not to
disclose.

- --
] Bear: "Me, I'm just the shape of a bear." | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr at xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

[Julien Laganier]

On Tuesday 03 April 2007 16:37, Michael Richardson
wrote:
> Julien Laganier <julien.IETF at laposte.net> writes:
>
> >> Possible reasons to reject
> >> public-keys-of-peers-as-channel-bindings:
> >>
> >> - doesn't work for IKEv2 w/ EAP
> >> authentication
>
> > When IKEv2 is used with EAP
> > authentication, the channel binding blob
> > could fallback from being peers' public keys to
> > a PRF of the EAP MSK. Both peers know that
> > EAP was used, so Julien> that doesn't even require
> > additional signalling to let peers generate
> > the appropriate blob.
>
> This suffers from all the problems that using
> something derived from the DH SKEYSEED has. I don't
> see a *BTNS* case for doing EAP and then using
> channel binding, but I might be wrong.

I don't see a case either. If EAP is used it means that
both peers were authenticated at the IPsec layer (the
initiator via EAP, the responder via a certificate,
and possibly also via EAP mutual authentication). Why
would someone want to authenticate "again" at the
IPsec layer via channel binding with an ULP...

Still it might be compelling to provide a channel
binding method anyway in case we're both wrong...

> (I can see BTNS for PARENT_SA "authentication",
> and then EAP for further authentication of the SA,
> but at which point, it might be unnecessary to
> actually do a channel binding. That's is in theory,
> but perhaps in practice, there isn't the total
> awareness necessary to avoid this.)
>
> I raised this question, because I felt that it
> needed to be resolved in some way, or resolved that
> we are comfortable with what we had already. The
> above proposal has the advantage that, like the
> concatenated public keys, it can be checked with
> memcmp().

Yes.

> This is the fundamental API issue. Is the API:
>
> #1 memcpy suffices:
>
> [...]

if(my_channel_binding_blob_len ==
his_channel_binding_blob_len &&
memcmp(my_channel_binding_blob,
his_channel_binding_blob,
his_channel_binding_blob_len)==0))

> [...]
>
> #2 channel binding needs to be checked:
>
> [...]

if(ipsec_check_channel_binding(my_channel_binding_blob,
my_channel_binding_blob_len,
his_channel_binding_blob,
his_channel_binding_blob_len)

> Obviously, case #1 can be implemented inside of case
> #2. Case #2 may, however, involve a round trip
> through the kernel to talk to the keying deamon if
> the channel binding blob can not be fully
> authenticated without key material that the keying
> daemon prefers not to disclose.

I think it's good if we spare the additional
userland-kernel RTT.

--julien

[Nicolas Williams]

On Tue, Apr 03, 2007 at 10:37:28AM -0400, Michael Richardson wrote:
> I don't see a *BTNS* case for doing EAP and then
> using channel binding, but I might be wrong.

Well, I don't see a use for channel binding to EAP-authenticated IPsec
channels (subtle difference).

That's because EAP, by its applicability, would be used in IPsec
VPN-type use cases, and so the end-points of the channel would be the
client and the SG, which have already authenticated each other, so why
authenticate again at the application layer?

> (I can see BTNS for PARENT_SA "authentication", and then EAP for
> further authentication of the SA, but at which point, it might be
> unnecessary to actually do a channel binding. That's is in theory, but
> perhaps in practice, there isn't the total awareness necessary to avoid
> this.)

Well, the channel binding could be done inside EAP, and this could be
used to enroll client public keys (a useful use case if you want to do
two-factor authentication where one factor is a BTNS key and it is
enrolled by one-time one-factor authentication).

> I raised this question, because I felt that it needed to be resolved
> in some way, or resolved that we are comfortable with what we had
> already. The above proposal has the advantage that, like the
> concatenated public keys, it can be checked with memcmp().

Unique and end-point channel bindings can both be checked with memcmp()
(or memcmp() of a hash/MAC of the channel bindings).

> /* do I look like I know anything about gssapi? */

No :)

Look at RFC2743 or RFC2744 and look at the function signatures for
GSS_Init_sec_context()/GSS_Accept_sec_context().

In the GSS-API (and in SASL/GS2) channel bindings are as an input to a
black box at each peer -- both have to provide the same channel binding
octet strings, else -> failure[*].

The black box can (and does, e.g., in the case of the Kerberos V GSS
mech) cause hashes/MACs of the channel bindings octet strings to be
exchanged.

[*] Total failure in the GSS-API case, partial failure for SASL/GS2.

Nico
--

[Michael Richardson]

>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
Nicolas> That's because EAP, by its applicability, would be used in
Nicolas> IPsec VPN-type use cases, and so the end-points of the
Nicolas> channel would be the client and the SG, which have already
Nicolas> authenticated each other, so why authenticate again at the
Nicolas> application layer?

Because the application layer isn't aware of whether or not the "VPN"
is actually active or not. Take the case of a laptop doing an NFS mount
of a server (assume NFS server and VPN gateway are co-located, such as
happens with a small office server).
When at "home", there is no tunnel, so the application needs to
authenticate. When remote, it can exploit the IPsec tunnel that exists.

(Ironically, if you have any hardware offload on the gateway, it would
actually be better to use the IPsec all the time, since the hardware is
likely faster, and you can, when local, probably get more use of it...)

Nicolas> Well, the channel binding could be done inside EAP, and
Nicolas> this could be used to enroll client public keys (a useful
Nicolas> use case if you want to do two-factor authentication where
Nicolas> one factor is a BTNS key and it is enrolled by one-time
Nicolas> one-factor authentication).

But, it still doesn't tell the application that it can avoid a second
layer of encryption.

Nicolas> Look at RFC2743 or RFC2744 and look at the function
Nicolas> signatures for
Nicolas> GSS_Init_sec_context()/GSS_Accept_sec_context().

Nicolas> In the GSS-API (and in SASL/GS2) channel bindings are as an
Nicolas> input to a black box at each peer -- both have to provide
Nicolas> the same channel binding octet strings, else -> failure[*].

Nicolas> The black box can (and does, e.g., in the case of the
Nicolas> Kerberos V GSS mech) cause hashes/MACs of the channel
Nicolas> bindings octet strings to be exchanged.

But are they compared with memcmp(), or with a function?

- --
] Bear: "Me, I'm just the shape of a bear." | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr at xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

[Nicolas Williams]

On Thu, Apr 05, 2007 at 09:33:00AM -0400, Michael Richardson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
> Nicolas> That's because EAP, by its applicability, would be used in
> Nicolas> IPsec VPN-type use cases, and so the end-points of the
> Nicolas> channel would be the client and the SG, which have already
> Nicolas> authenticated each other, so why authenticate again at the
> Nicolas> application layer?
>
> Because the application layer isn't aware of whether or not the "VPN"
> is actually active or not. Take the case of a laptop doing an NFS mount
> of a server (assume NFS server and VPN gateway are co-located, such as
> happens with a small office server).
> When at "home", there is no tunnel, so the application needs to
> authenticate. When remote, it can exploit the IPsec tunnel that exists.

OK, that's a probable use case.

[Nicolas Williams]

On Thu, Apr 05, 2007 at 09:33:00AM -0400, Michael Richardson wrote:
> >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
> Nicolas> In the GSS-API (and in SASL/GS2) channel bindings are as an
> Nicolas> input to a black box at each peer -- both have to provide
> Nicolas> the same channel binding octet strings, else -> failure[*].
>
> Nicolas> The black box can (and does, e.g., in the case of the
> Nicolas> Kerberos V GSS mech) cause hashes/MACs of the channel
> Nicolas> bindings octet strings to be exchanged.
>
> But are they compared with memcmp(), or with a function?

Something is compared, but the something isn't necessarily the raw
channel binding octet string.

It could be a hash of them, it could that the channel bindings are used
in key derivation so that an "authenticator" message is what gets
compared, etc...

In the case of SASL/GS2 the raw channel binding octet string is
memcmp()ed. In the case of the Kerberos V GSS-API mechanism (and, I
think, the upcoming replacement for SPKM, 'PKU2U'), hash or a MAC of the
channel binding octet string is memcmp()ed.

Nico
--

[Nicolas Williams]

On Tue, Apr 03, 2007 at 03:37:57PM +0200, Julien Laganier wrote:
> > - doesn't work for IKEv2 w/ EAP authentication
>
> When IKEv2 is used with EAP authentication, the channel
> binding blob could fallback from being peers' public
> keys to a PRF of the EAP MSK. Both peers know that EAP
> was used, so that doesn't even require additional
> signalling to let peers generate the appropriate blob.

That's true, we could do that.

We could also specify both kinds of channel binding for IPsec and let
ULPs and/or application protocols decide which to use.

For example: TCP (and any protocol like it that has a handshake at the
beginning) can recover from IKE_SA expiration by simply not
retransmitting the SYN packet protected with an SA such that the
SKEYSEED-based channel bindings would be different than for the first
SYN -- instead TCP can fail the connect() with a suitable error code or
even begin again with a new 5-tuple (diff client side ephemeral port #).

Whereas for "connected" UDP we either have to accept that SKEYSEED-based
channel bindings break across IKE_SA expiration/abandonment or we have
to accept end-point public keys as the channel bindings.

For unconnected UDP we can leave the matter to the application: if it
has a TCP-like handshake then the app can deal with SKEYSEED-based
channel bindings just like TCP could, else see above.

This could be a suitable compromise because it means we can have unique
channel bindings (SKEYSEED-based) in more places. "Unique channel
bindings" are preferable over "end-point channel bindigs" because they
can double as nonce/challenge in application layers to obtain
authentication replay protection with fewer messages or w/o clock
synchronization + replay caches.

Nico
--