PAS issue 14 - leap of faith

On Mon, Apr 03, 2006 at 05:52:41PM -0400, Stephen Kent
wrote:
> >>  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.

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

> In the IPsec context, this translates into creating a
PAD entry based 
> 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, 
> 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.

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
-- 
_______________________________________________

Nico,

>...
>
>>  In the IPsec context, this translates into
creating a PAD entry based
>>  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.

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.

>  >                                    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.
>
>The problem is that w/o IPsec-specific APIs the only
"IDs" seen by the
>application through traditional APIs are, in fact, IP
addresses.

yes, and even those are indirect references, since the apps
usually 
employ names, not 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.

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.

>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.

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.

>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.

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
_______________________________________________