Subject: [anonsec] PAS issue 14 - leap of faith

From: kent at bbn.com (Stephen Kent)
Date: Mon, 3 Apr 2006 17:52:41 -0400

At 5:35 PM -0800 3/27/06, Joe Touch wrote:
>Nicolas Williams wrote:
>>  On Mon, Mar 27, 2006 at 01:47:46PM -0800, Joe Touch wrote:
>>>  As I noted, when those anchors are insufficient:
>>>
>>>	- on the server side, LOF occurs (just accepts the user's cert)
>>>	- on the client side, the app asks the user to authenticate
>>>	the cert; most users tend to just click 'yes' (LOF), whereas
>>>	some check the cert (more like out-of-band auth)
>>
>>  I think I'm ready to assert:
>>
>>  a) LoF is meaningful only where actual authentication of the peer is
>>     desired; not caring at all requires no "leap";
>
>That makes no sense to me, nor does it match anything I could find in
>the literature. LOF seems precisely about blind acceptance of the first
>certificate presented without authentication.

I agree with Nico. The essence of LoF is that a user accepts a 
credential (a cert that will be viewed as a trust anchor for SSL, a 
public key for a server in SSH) under the assumption that there is no 
MITM attack taking place at the time of exchange with the server, and 
that the ID and key asserted in the exchange is accurate. After that 
initial exchange where the LoF takes place, subsequent communication 
is authenticated based on the credential that was accepted, and is 
resistant to MITM attacks.

In the IPsec context, this translates into creating a PAD entry based 
on a unauthenticated IKE exchange. The difference here is that IPsec, 
unlike SSH and SSL, implements access control and thus the ID bound 
to the key directly affects the protocol operation in this regard. So 
we have to be very careful what form  of IDs are installed in a PAD 
entry under an LoF model of operation. For example, addresses might 
be inappropriate (due to DHCP and mobility) but names might be OK.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 4 Apr 2006 09:53:29 -0500

> resistant to MITM attacks.

Right, so the BTNS core I-D only provides for "not caring at all" about
authentication and leaves LoF to some other document.

> on a unauthenticated IKE exchange.

This is the first one of two methods we've considered so far.

The second method involves connection latching and pushes the
responsibility for LoF to the application.

I *much* prefer the second method.

>                                    The difference here is that IPsec, 

The problem is that w/o IPsec-specific APIs the only "IDs" seen by the
application through traditional APIs are, in fact, IP addresses.

You've just re-identified the problem: IPsec LoF requires IPsec-specific
APIs to avoid dynamic address consumption (read: DoS attacks), and it
requires application involvement.

We just agreed that we don't want strong bindings between PUBLICKEY IDs
and addresses; we also don't want to allow theft of packet flows at SA
expiration/renewal time, and we don't want very long SA lifetimes to
create stronger publickey/address bindings than we're willing to
tolerate.  Which, IMO, argues for connection latching.

If you'll accept IPsec APIs at all then I think you'll find the second
LoF method (see above) more appealing than the first.

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Tue, 4 Apr 2006 13:14:00 -0400

Nico,

>...

in that case, IPsec is not providing LoF support per se, as the 
responsibility is assumed by the application.

>I *much* prefer the second method.

no argument from me.

>application through traditional APIs are, in fact, IP addresses.

yes, and even those are indirect references, since the apps usually 
employ names, not addresses

>requires application involvement.

Most of the discussion here seems to entail application involvement, 
so that does not seem like an issue, whether we're discussing APIs, 
etc. What I tried to do was to note that because IPsec enforces 
access control decisions based on IDs, LoF has different implications 
here vs in security protocols that do not offer access control 
functionality at all.

>tolerate.  Which, IMO, argues for connection latching.

there are contexts in which bindings between PK IDs and addresses are 
feasible and maybe even desirable, but those are not the most general 
cases.

>LoF method (see above) more appealing than the first.

I understand your preference here. APIs may be fine in many contexts, 
but they also may undermine the extant access control model in some 
other contexts.  We need to provide suitable explanations of when 
these concerns arise, so that folks are not surprised by the results.

Streve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 4 Apr 2006 13:05:36 -0500

> >I *much* prefer the second method.

Looks like we're in violent agreement.

Implicit here is support for connection latching and some IPsec APIs
(these are abstractly described in the connection latching I-D); if I'm
reading you incorrectly let us know.

> here vs in security protocols that do not offer access control 

More violent agreement.

> feasible and maybe even desirable, but those are not the most general 

I believe Joe's original BTNS use case is one such case, and I agree
that it is not a general case.

IMO in general LoF is best handled by applications.

> these concerns arise, so that folks are not surprised by the results.

Of course.  I expect that the end result will tell implementors when
BTNS is applicable and will specifically recommend use of BTNS with SPD
entries that limits BTNS to protocols whose applications are expected to
use channel bindings or LoF.  Specific examples may involved NFSv4,
SSHv2, TLS (provided all are modified to support channel binding/LoF).

Also, BGP (Joe's use case :)

Nico
--

---

From: pekka.nikander at nomadiclab.com (Pekka Nikander)
Date: Mon, 10 Apr 2006 13:04:30 +0300

Steve and Nico,

>> I *much* prefer the second method.

That makes perfect sense to me.  In any case, the context (i.e. the  
PUBLICKEY) should be bound to the app that is using it, lest you find  
yourself with very interesting phishy dragons where an attacker  
creates a LoF binding in one context (e.g. online game) and then  
lures the user to use it in another context (e.g. banking).  That  
taking place, the second context (banking) appears secure to the  
user.  I am to see the user interface that would make the dangers  
involved clear to the average user.

Note that with SSH this has not really been a problem, since SSH port  
forwarding has mostly been used only by knowledgeable people and with  
their consent.

> feasible and maybe even desirable, but those are not the most general

I agree.  We just need to understand that such context are  
characterised by someone being "responsible" for the IP address  
ranger under consideration, and that the same (or strongly related)  
party is responsible for creating the bindings between the PK IDs and  
the addresses.

The problem we are facing here is that not even a single body is  
responsible for assigning the addresses here, making it impossible to  
manage the bindings in any sensible terms.

> these concerns arise, so that folks are not surprised by the results.

I agree.   It is in interesting mental exercise to consider the HIP  
ACL model here; in HIP the inner IP addresses are replaced by  
references to the public keys, at the socket API, in apps, and in  
apps protocols,

--Pekka

---

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Fri, 21 Apr 2006 15:43:00 -0400

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 480 bytes
Desc: not available
Url : http://www.postel.org/pipermail/anonsec/attachments/20060421/6e6336de/attachment.bin

---

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Fri, 21 Apr 2006 15:48:12 -0400

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 480 bytes
Desc: not available
Url : http://www.postel.org/pipermail/anonsec/attachments/20060421/9648dd67/attachment.bin