[anonsec] PAS issue 14 - leap of faith

[Nicolas Williams]

On Mon, Mar 27, 2006 at 12:57:57PM -0800, Joe Touch wrote:
> Nicolas Williams wrote:
> > On Mon, Mar 27, 2006 at 11:19:27AM -0800, Joe Touch wrote:
> > 
> > My version:
> > 
> > 1. leap of faith = accepting an unauthenticated peer when authentication
> >                    of it is otherwise desired
> > 
> >    Here "faith" refers to the belief, or rather, hope that the peer is
> >    not being impersonated by an active attacker.
> > 
> >> 	SSH servers do this automatically for client certificates, e.g.
> >                                               ^^^^^^ ^^^^^^^^^^^^
> > 					      server public keys
> 
> I meant client public keys. The auto-part is done at the server for the
> client info.

That was something we discussed some months ago.  I think it's what you
wanted for your BGP use case, and it may make sense in that context, ...

...but because of the dynamic address space consumption problem we
discussed at Vancouver it's not generally useful.

I think client-side LoF can be useful far more often than server-side
LoF.  At the very least we should distinguish between the two.

> The clients typically do NOT accept unauthenticated server public keys;
> they typically ask the user to authenticate them (as per below).

But they (the users) don't [authenticate server public keys] -- they
take a "leap of faith" that those are the correct keys.

> >> 	SSH clients typically ask users to verify certificates that
> >> 	otherwise cannot be authenticated in-band; this *assumes*
> >> 	out-of-band authentication of the certificate. One can consider
> >> 	users who blindly 'accept' those certificates to be performing
> >> 	a similar 'leap of faith' at the user level, though.
> > 
> > Not "consider" -- that *is* what leap of faith means in an SSH context:
> > that the user is asked to do something they often can't and so typically
> > accept a peer without further ado, on "faith" as it were.
> 
> It's really useful to distinguish between what the user does (typically
> 'leaps') and what the protocol thinks it's doing (delegating
> authentication to a user process). SSH isn't taking the leap there.

It is the user taking the leap, absolutely,which is why I insisted
earlier on asking where in the stack (and which peer) LoF would function
in BTNS LoF.

But the protocol, by providing ad-hoc authentication schemes, does imply
LoF in actuality since that's the best that users can do.

> >> I was reminded that such caching is irrelevant to IKE, i.e., that keys
> >> need not be cached to prevent hijacking, since SAs can be torn down only
> >> if the child of a parent SA (can anyone confirm?).
> > 
> > This question is not important because you need connection latching to
> > protect you from the wildcard matching problems discussed and that, in
> > turn, provides a binding between individual packet flows and their
> > end-point IDs.
> 
> Doesn't the need for (and utility of) connection latching presume
> channel binding? I.e., in the case where there is no channel binding,
> this doesn't seem relevant.

No.  With connection latching we can have the application (possibly
through interaction with the user) perform SSH-like LoF _at the
application layer_.

Incidentally, this thread convinces me (ok, I've convinced myself :)
that LoF really belongs at the application layer.  At its core BTNS
should simply require that policy identify traffic types (port numbers,
etc) that should be allowed and protected even with unauthenticated
peers on account of measures taken by the applications driving such
traffic flows; such measures include channel binding and LoF.

A contrived example of BTNS + LoF based on the SSH model would be SSH
itself: given IPsec, BTNS, connection latching and an API for obtaining
the latched IDs/keys then SSHv2 clients and servers could negotiate the
use of the none cipher/MAC at the SSHv2 layer, relying instead on ESP/AH
to provide the desired QoP.  In this contrived example the client would
still have to ask the user to "validate" any servers' BTNS public keys,
so users would continue to take "leaps of faith."

That example may not be so contrived, actually, in that given
sufficiently advanced ESP/AH offload in NICs and bulk applications
running over SSHv2 then this scheme I posit may be desirable, not merely
fantasy.

A non-contrived example of BTNS + LoF might be your original BGP use
case (feel free to elaborate).

A non-contrived example of channel binding is NFSv4.  I won't repeat
that right now, to avoid sounding like a broken record :)

Cheers,

Nico
--