Subject: [anonsec] draft-williams-btns-00.txt

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 14 Sep 2005 00:59:52 -0500

A new I-D, draft-williams-btns-00.txt, based on feedback at Paris and on
the list is now available.

Nico
--

---

From: jari.arkko at piuha.net (Jari Arkko)
Date: Wed, 14 Sep 2005 13:03:22 +0300

This draft is major improvement from the previous one.
Overall, I like the approach. Its simple. It seems to satisfy both
goals that I think are important, i.e., "anonymous
encryption" (= unauthenticated SA) and "leap of faith" styles.
I like the way that this is integrated to the rest of the policy
processing.

Some comments below, however:

Technical:

>4.  Security Considerations
>
Is there an issue with the use of tunnel mode without
proper settings? E.g., A establishes a tunnel mode SA
with the a gateway that uses A's addresses on the
outside but B's addresses on the inside, grabbing
B's traffic. (But I may be missing something here.)

Another potential issue is establishing a btns-willing
node as a gateway to tunnel illegal traffic through this
unsuspecting victim.

>Another possible
>   mitigation would be to prompt a user about each leap-of-faith BTNS
>   policy entry instantiation.
>  
>
The text should probably say something about this being
hard. For instance, a router sitting in a cabinet may not
have means to ask its "user" about whether the new entry
is appropriate.

>3.  Leap-of-Faith BTNS
>
>   Implementors may provide a PAD entry attribute used to indicate that
>   the given PAD entry is a template that should, when matched, cause
>   new PAD and SPD entries to be created binding the matching peer's IP
>   address and BTNS ID (i.e., public key) by using the PUBLICKEY ID
>   selector to match on the peer's public key.  Entries created this way
>   have to be persistent, for some value of "persistent," though we
>   RECOMMEND that "persistent" mean "until manually removed.
>  
>
The interesting question is what IP address you are talking
about above. I think you mean the peer's address that is
visible in the IKE packets. But I wonder if that's the best
approach. You could also imagine binding between the ID
and the inner address. In transport mode there's no
difference, but in tunnel mode the relevant address is
really the inner one.

What about IKEv2's configuration mechanisms, would
that be tied to this binding? E.g., when you connect
for the first time, you will be allocated an IP address
and then on subsequent connections, you will get/
must use that same IP address.

>   Use with applications that bind authentication at higher network
>   layers to secure channels at lower layers may provide one secure way
>   to use unauthenticated IPsec, but this is not specified herein and.
>  
>
Question: In IKEv2 EAP mode the gateway end needs to
be authenticated by a cert, even if there might be
mutual authentication in the underlying EAP scheme
that is being used. Does this draft allow the usage
of unauthenticated mode in this scenario?

Editorial:

>   The conditions under which a BTNS-capable IKE/IKEv2 implementation
>   MUST accept an IKE_SA that it would otherwise reject are such where
>   the reasons for rejection relate only to the peer's CERT payload,
>   namely:
>  
>
Is MUST really appropriate here, or this rather a SHOULD?

>   Implementors may provide a PAD entry attribute used to indicate that
>
s/may/MAY/ ?

>   o  For BTNS IKE and IKEv2 MUST coerce the IDs of peers whose CERT
>      payloads could not be validated (in certain conditions, see below)
>      to PUBLICKEY IDs whose values correspond to the public key used by
>      the peer (if the peer used a certificate, then the certificate's
>      subjectPublicKey) that can only be matched by either the 'UNKNOWN'
>      ID selector wildcard value or a PUBLICKEY ID selector with that
>      same key as its value; of course, HASH/AUTH payloads must be
>      validated.
>  
>
This paragraph was hard to parse.

--Jari

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 14 Sep 2005 09:46:43 -0500

> I like the way that this is integrated to the rest of the policy

Glad you like it; much credit goes to Charlie and all who commented on
the previous I-D.

> node as a gateway to tunnel illegal traffic through this

There's two issues with tunnelling:

 - applications can't do channel bindings to tunnels (one end-point may
   see the tunnel, but the other won't, unless the other is at the SG);

 - a tunnel can carry traffic for many nodes which might consider BTNS
   inappropriate but have no choice as they have no knowledge of what
   the SG is doing, whereas end-to-end BTNS can only carry traffic for
   two nodes that have all the information they need to decide whether
   to engage in conversation.

Now, you could start a BTNS tunnel, then run an application at the
client and SG to do authentication and channel binding, then start
actual packet forwarding at the SG; that would be fine.  But I think
that would: a) be out of scope for this I-D, b) replicate functionality
that's already in IKEv2.  So I'd rather limit this I-D to end-to-end
IPsec and leave tunnels out of scope.

> have means to ask its "user" about whether the new entry

Sure.

> difference, but in tunnel mode the relevant address is

Since we're talking end-to-end, not tunnels, there should be no
ambiguity as to which IP address to use, no?

> must use that same IP address.

Would this be used in non-tunnel situations?

> of unauthenticated mode in this scenario?

I'd rather not address tunnels here, but, I could see this being allowed
provided that the selected EAP method provides EAP cryptographic and
channel bindings and is acceptable to the client for use w/o SG certs.

> Is MUST really appropriate here, or this rather a SHOULD?

I think MUST as this is necessary for BTNS to work, but don't yet feel
strongly about it.

> >  Implementors may provide a PAD entry attribute used to indicate that

I'd be happy either way.

> This paragraph was hard to parse.

Would removing the parentheticals and splitting the sentence at "that"
and at the semi-colon help?  The text in the second paren could be made
a separate sentence too.  I'll smith it.

Nico
--

---

From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Wed, 14 Sep 2005 12:16:52 -0400

On Wed, 2005-09-14 at 10:46, Nicolas Williams wrote:
> So I'd rather limit this I-D to end-to-end IPsec and leave tunnels out
> of scope.

Agreed.

My preference would be for transport mode only, but I can live with
using a "self-tunnel" mode where the respective inner and outer
addresses are required to match.

						- Bill

---

From: lha at it.su.se (Love Hörnquist Åstrand)
Date: Wed, 14 Sep 2005 18:35:46 +0200

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 477 bytes
Desc: not available
Url : http://www.postel.org/pipermail/anonsec/attachments/20050914/732788ca/attachment.bin

---

From: jari.arkko at piuha.net (Jari Arkko)
Date: Thu, 15 Sep 2005 02:10:12 +0300

>addresses are required to match.
I think we need to do one of three things - document that
the configuration of btns with tunnel mode is a bad idea,
require implementations to prevent this, or to develop
some specific rules when tunnel mode usage is safe (and
useful - this may be the harder exercise).

I also think that the default assumption is transport mode
only, but I'm not sure I personally understand all aspects
of this decision yet. Specifically, it might be interesting
to think some more about the potential implications wrt
usage scenarios. Is there some potential usage that we
are preventing if we don't allow tunnel mode? I don't
see any right now, but it doesn't mean that they don't
exist...

--Jari

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 14 Sep 2005 21:43:37 -0500

> see any right now, but it doesn't mean that they don't

None that couldn't be enabled through a separate I-D.  We should
explicitly leave tunnel mode BTNS out of scope; I see explaining why
as gravy, though I certainly don't mind.

I did describe a reasonable use for tunnel mode BTNS earlier, but it's
nothing that couldn't be done with IKEv2 w/ EAP...

Cheers,

Nico
--

---

From: pekka.nikander at nomadiclab.com (Pekka Nikander)
Date: Thu, 15 Sep 2005 09:19:06 +0200

> are preventing if we don't allow tunnel mode?

IIRC, someone (David Black?) mentioned at the Paris meeting that some  
IP storage solutions currently require tunnel mode.  Therefore our  
f2f decision was to include tunnel mode where the inner and outer  
addresses are equal.

 From the minutes: (http://www.ietf.org/proceedings/05aug/minutes/ 
btns.html)

1. Need to support tunnel mode where inner address is the same as  
outer address.

This is because of requirements of other protocols, such as iSCSI  
that have tunnel mode as MUST.

--Pekka

---

From: kivinen at iki.fi (Tero Kivinen)
Date: Thu, 15 Sep 2005 14:26:16 +0300

> f2f decision was to include tunnel mode where the inner and outer  

Also NAT-T is simplier if done on tunnel mode, no need to mess around
with original IP-addresses and updating checksums. In NAT-T case the
inner and outer addresses are not equal, as outer address is the
NAT-boxeses address, and inner address is the endpoints address. I do
not think if the NAT-T is relevant to the btns...
-- 
kivinen at safenet-inc.com

---

From: jari.arkko at piuha.net (Jari Arkko)
Date: Thu, 15 Sep 2005 15:13:34 +0300

>not think if the NAT-T is relevant to the btns...
NAT-T is probably relevant to anything that deals
with end-user devices. Anyway, the same problem with
addresses not being equal appears also in MOBIKE,
should that be used together with BTNS (and it too
only works for tunnel mode, at least for now).

--Jari

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 15 Sep 2005 11:12:29 -0500

> that have tunnel mode as MUST.

Tunnelling, as opposed to "tunnel mode" SAs, is what would be out of
scope in the I-D.

To me that's the real distinction between "tunnel" and "transport" --
not labelling on the wire in IKE, or in an SADB, but how the things are
used.  Tunnels are, well tunnels, and you can make tunnels out of
transport mode IPsec by doing IP-IP tunnelling.  Similarly there's no
requirement that tunnel mode SAs be used for anything other than
end-to-end purposes.

Nico
--

---

From: mohanp at sbcglobal.net (Mohan Parthasarathy)
Date: Thu, 15 Sep 2005 13:11:06 -0700

> useful - this may be the harder exercise).
Perhaps, i missed the discussion earlier. What is the problem with supporting
it for tunnel mode ?

thanks
mohan

> _______________________________________________

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 15 Sep 2005 15:47:22 -0500

> Perhaps, i missed the discussion earlier. What is the problem with supporting

http://www.postel.org/pipermail/anonsec/2005-September/date.html