Subject: [anonsec] review of draft-williams-btns-unauthenticated-bits-00.txt

From: jari.arkko at piuha.net (Jari Arkko)
Date: Mon, 15 Aug 2005 13:11:15 +0300

Hi Nicolas,

I finally found some time to read this draft.

(Disclaimer: Due to a conflict I could not stay the whole
BTNS meeting in IETF-63, and I also have not followed
list discussion. So I may be bringing up issues that you
already discussed.)

Overall, I like the approach. I have some smaller issues
and one bigger technical issue. First the big issue:

>    This, then, is a crucial feature of BTNS mode IPsec: that it is most
>    useful (and least harmful) when used between systems with statically
>    allocated addresses and whose BTNS keys change infrequently.

This worries me quite a bit. In today's network situation
this is quite limiting, particularly if you consider that
most server-to-server connections probably would use
managed security rather than anonymous security.

It may be that the combination of BTNS and MOBIKE might
help here (probably will), or that we should start asking
ourselves whether the binding to the IP address is really
useful basis for BTNS. One approach would be to scope
BTNS as an anonymous encryption scheme rather than
leap-of-faith. That is, you could use it as a means to
opportunistically protect all your communications, but you
would not get any guarantees that you are talking to the
same node beyond the life of the IKE SA. But this would
possibly preclude the use of BTNS for the BGP application
(or would it? i don't know).

One way to deal with this would be to add not one, but two
additional authentication modes to the PAD:

Leap-of-faith: If you successfully execute an unauthenticated
IKEv2 run with the peer, then latch on to the key communicated during
that run, and require that key in all subsequent IKEv2 runs to
or from that same address. This would most likely be used only
with PAD entries that have been limited to a given peer address
or a range of addresses, and a limited application.

Anonymous encryption: Set up IKEv2 runs with peers in an
opportunistic manner, without keeping any state from old
connections to this address. Allow another IKEv2 run to
clear the state (as in INITIAL_CONTACT). This is useful for
protecting against non-path attackers and for on-path
attackers that do not wish to execute a D-H MITM attack
on every connection passing through.

>    Another crucial feature of BTNS mode IPsec: it MUST be possible to
>    manually edit a PAD on a BITS (or BITW) implementation to remove
>    stale BTNS entries.

This is a related problem. Such manual edits are a non-starter for
general population usage, though of course possible in limited
applications. I would suggest making anonymous encryption the
mandatory-to-implement feature and then requiring the above
MUST only if Leap-of-Faith mode is supported.

Then to the smaller issues:

>    This document specifies how to use the Internet Key Exchange (IKE)
>    protocols, such as IKEv1 and IKEv2, to setup "unauthenticated"

For simplicity, I'd prefer doing this for IKEv2 only.

>    IKE peers, both v1 and v2, when receiving a peer's ID_PUBLICKEY MAY,
>    of course, reject the exchange according to local policy (i.e., if
>    the peer is not authorized to assert the given public key as its ID).

What is the process of rejection, and will it consist of informing
the client that the problem was lack of authorization for anonauth?
This may be important, if we have a large number of IKE capable
nodes in the Internet but not all of them supporting BTNS.

Other issues:

I don't see anything about the symmetric or asymmetric nature of this
extension. Can you do anonsec one way or two way or both?

Is this only for transport mode? Presumably yes, I'm not sure we
want to deal with issues relating to authorizing specific inner
addresses.

Also, I don't see any discussion about the role of user confirmation
in the leap-of-faith scheme, or the security implications for the lack
of such confirmation. SSH and SIP leap of faith schemes employ
such confirmations, and for those application it appears rather
essential for the security.

Mobike integration: in the leap-of-faith case, it seems that one
could easily allow the address associated with the public key
to change (or even have multiple concurrent addresses). What
we still want to ensure that you can't override someone else's
PAD entry. Arranging this seems problematic, because in a
DHCP v4 environment you could easily get someone else's
old address, and at IP layer the other end does not know if
its still using that other address or not.

--Jari

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 15 Aug 2005 10:30:51 -0500

> list discussion. So I may be bringing up issues that you

What you missed is that I said to ignore the -00.

My goal with that -00 had been to show how useless BTNS is without APIs,
but partly this was based on a misunderstanding that led me to think
that leap-of-faith creation of PAD entries would be needed.

I now realize my error and am dropping the leap-of-faith stuff.

Further, Charlie Kaufman argued that we needed no extensions to IKE or
IKEv2, not on the wire anyways.  In a subsequent hallway meeting he
convinced me and then we discussed just what PAD/SPD extensions we might
need, and we came up with this: we need a new ID selector wildcard
value, just like "ANY" but meaning "any peer, BTNS or otherwise."

(And we need this new selector only so that configurations using the old
selector don't suddenly allow BTNS where it was never intended when the
implementations are upgraded to ones that support BTNS.)

So, to sum up, the current state of thinking on BTNS is that we need no
IKE extensions, just a new ID selector wildcard for PAD and SPD entries,
which we may be calling 'UNKNOWN'; IKE/IKEv2 implementations have to
understand 'UNKNOWN', of course, and we may still need a new ID type
just so we can internally represent the "identities" of BTNS peers.

I'll answer any of your points that aren't answered by this later.

Thanks!

Nico
--