[anonsec] PAS issue 14 - leap of faith

[Nicolas Williams]

On Tue, Apr 04, 2006 at 01:14:00PM -0400, Stephen Kent wrote:
> Nico,
> 
> >I *much* prefer the second method.
> 
> no argument from me.

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.

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

More violent agreement.

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

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.

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

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