Subject: [anonsec] what I call leap-of-faith

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Mon, 20 Mar 2006 15:59:13 -0600

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/20060320/8a7af661/attachment.bin

---

From: yushunwa at ISI.EDU (Yu-Shun Wang)
Date: Thu, 23 Mar 2006 11:13:04 -0600

Hi, Michael,

Comments below.

Michael Richardson wrote:
> When you SSH to a host the server sends it's public key inline.
> 
> The client checks against a local database it has (~/.ssh/known_hosts for ssh
> 1 and openssh, ~/ssh2/hostkeys/key_PORT_NAME for ssh.com ssh2). You can
> populate these yourself if you want.
> 
> If the entry is not found, the user is presented with a finger print (hex and
> bubble-babble are common), and asked if they want to check it. The user types
> "y" or "n". Some users call up the admin and ask for the fingerprint, others
> just make a leap-of-faith: that they are not being MITM attacked at that
> moment.
> 
> ssh.com ssh now stores things by the name that you type on the command
> line + port number. openssh stores by IP and name. This causes problems if
> you have ssh servers on different port numbers, such as having port 222
> portforwarded by you NAT to some host behind it --- I mention this because
> the public is bound to a name in different ways by different vendors.
> 
> The leap-of-faith is that the user is consulted as an oracle to make the hard
> decision.  Modern SSH implementations will now for instance, turn off password
> authentication when the host is not yet known, to avoid disclosing the
> password to a MITM.
> 
> If I was doing leap-of-faith for IPsec, as a peer that doesn't have an active
> user that can be contacted, then I'd accept to create the PARENT SA, and then
> limit the CHILD SA to what would otherwise be permitted as plaintext.

If channel binding is to be used, I thought CB doesn't
or shouldn't send passwords in cleartext?

> When we store the key, we have to be careful about storing it by IP
> address. I would not do that, as I have no way of knowing if the IP address
> is permanent or ephermeral.
> 
> I see no major problem with storing the keys by other IDs, particularly
> random DN.
> 
> The leap-of-faith would be when the admin took the key, and "locked it down",
> i.e. loaded it into the trusted-store and attached some kind of SPD entry to
> it.   I.e. the leap-of-faith takes this peer from being BTNS to being
> "normal" IPsec, with the exchanging of authentication material having been
> facilitated by BTNS in-band.
> (How the admin checked the key is by definition out of scope)

Disagree on the last point, though it's subtle and not sure
how significant it'll be. When SSH stores the key from the
LoF, it means two thing:

- It's a leap of faith for _this_ connection.
- By storing the key for future use, one is extending the
   leap of faith for future connections until noted otherwise.

This is similar to answering "Accepting this CA cert
permanently" when prompted by web browsers.

For both cases, they are still leap of faith, and are still
unauthenticated (if no channel binding). It should not be
treated or converted to _normal_ (authenticated) IPsec just
because the leap of faith is extended. Bottom line: the
auth credential is still unauthenticated in PAD, so IMO
presenting it otherwise would be dangerous. I admit that
in doing so, the applications, SSH & browsers, are essentially
treating such extended LoF as "normal" by bypassing the
prompts. But it's different to do so in protocols. Actually,
now that I think about it, adding SPD probably doesn't make
it "normal" (non-BTNS) IPsec because it's PAD that matters.
Steve will know for sure.

Finally, I am not sure if adding SPD entries because of BTNS is
a good idea or not. Although it seems like the actual policy
regarding authentication is in PAD in 4301 now, SPD is
still part of the policy database and I've always thought
BTNS should be specified by policy but not creating policy?
Maybe this is related to Sam's comments re: API or interfaces
to SPD? But I thought that's from _outside_ of IPsec such as
other protocols or apps.

yushun

---

From: kivinen at iki.fi (Tero Kivinen)
Date: Thu, 23 Mar 2006 19:25:44 +0200

> the public is bound to a name in different ways by different vendors.

The important thing there is to store AND match the identity user
indicated to the database, without doing any unsecure modifcations to
it (dns lookups, adding search path etc). There are attacks which can
be done if those are done. I.e. the database lookup should be based
only on the thing user typed in.

One of the features implementations do not yet have is to do reverse
matching of the keys, i.e. if the key is not found from the database
using the identity given by user, then search the database for the
matching public key, and instead of print "unknown host dialog", print
out "Unknown host, but the samepublic key was previous used by host
foo". This solves the problem where you ssh into your laptop in the
remote network, where it might have unknown name and ip, but you can
still find the matching public key from your database matching our
"mylaptop.mynetwork.com" entry.

Also implementations should give out the option to use make temporary
connection,i.e. not to stopre information to the database permanently. 

> is permanent or ephermeral.

The problem with btns use of leap-of-faith is that quite often the
IP-address is the only thing we have. My application might have some
other identity (like dns-name), but when the packets finally end up to
the ipsec level there is nothing left than the IP-address. If we do
not have any specific policy for that host, then we do not have any
other ID than IP address.

Again here comes those gui-options in to important role. The user
quite often knows whether the IP address he is connecting is permanent
or not, he also knows whether he wants to insert the data to database
or not. Also doing reverse lookup based on the public key for unknown
identities will help user again to ntoice that all ip-addresses of for
example www.google.com do match to the same key, especially if when
adding to the new identity is added to the database the user is also
given option to add extra comments. 

> I see no major problem with storing the keys by other IDs, particularly

Where do you get that DN or other IDs? You should not really trust the
other end sending you ID claiming to be www.example.com when you are
connecting to the www.evil.org.

-- 
kivinen at safenet-inc.com

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 23 Mar 2006 11:46:21 -0600

> When you SSH to a host the server sends it's public key inline.
[...]

Note that this is a very application-centric view of LoF.

And maybe that's what we can do in this context through use of
connection-latching and IPsec APIs.  That is, let the app get peer IDs,
channel bindings, out of latched connections and then perform LoF at the
application layer.

Doing LoF at the IPsec layer gets us into all those issues we talked
about.

Note too that, given APIs to manipulate the IPsec DBs (PAD, SPD, SADB)
applications could apply LoF not only at the app layer, but also enforce
it in the PAD by creating PAD entries that bind BTNS publickey IDs and
node addresses, though I wouldn't recommend it.

Nico
--

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 23 Mar 2006 14:36:32 -0800

Maybe it'd be useful to pose the questions separately, i.e., what should
each of the following steps be called>

1. accepting the first unauthenticated certificate (U-C)

2. deciding to cache accepted U-Cs for future use

3. referring to the blind acceptance of cached U-Cs when matching

Where's the leap? Is it in:
	- accepting the first UC
	- assuming that matching UCs mean matching endpoints
	- somewhere else?

Joe

Yu-Shun Wang wrote:
> _______________________________________________

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 23 Mar 2006 16:57:45 -0600

> 	- assuming that matching UCs mean matching endpoints

The better question is: where is the leap taken?  If it's taken by the
app, then we avoid the problems we discussed at Vancouver, whereas if
it's taken in the KE (by creating LoF PAD entries binding the peer
address and public key) then we run into those problems.

Also, looking at the SSH example, LoF is usefully done on a client, not
a server -- the server doesn't care about the client's public key since
the client will be authenticating at the app layer and connection
latching and channel bindings will protect against MITMs, but the client
cares because once it knows a server's public key it might be willing to
send passwords/session ID cookies (for "fast re-authentication") and
what not over the latched connection.

Nico
--

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 23 Mar 2006 17:42:01 -0600

On Mon, Mar 20, 2006 at 03:59:13PM -0600, Michael Richardson wrote:
> decision.

The leap-of-faith is what the user effectively has to do: he has to
trust that (have faith in) his client's server is the one the user
wanted -- the user has no realistic way of verifying this, so he has to
take a 'leap' and just blindly believe it.

>            Modern SSH implementations will now for instance, turn off password

Yup.

> limit the CHILD SA to what would otherwise be permitted as plaintext.

Well, the BTNS core doc allows just that (the administrator has to
provide policy, of course).

But a BTNS client could do LoF much like SSH clients given connection
latching and APIs to retrieve the peer's ID type/value (if it's
PUBLICKEY/... then BTNS was used and the client can look for the key in
a known_hosts database and/or LoF).

> is permanent or ephermeral.

Yes, that gets you into the problems we discussed at Vancouver.

> I see no major problem with storing the keys by other IDs, particularly

Or whatever name a user passed to the client UI.

> (How the admin checked the key is by definition out of scope)

This is what we discussed at Vancouver.  (Or was it Paris?  Anyways.)

Sure, the admin could create PAD and SPD entries binding an address/key
pair, subject to the pains created by dynamic addressing.  APIs like Sam
was asking for would help make this possible :)

Nico
--

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 23 Mar 2006 17:47:13 -0600

On Thu, Mar 23, 2006 at 11:13:04AM -0600, Yu-Shun Wang wrote:
> a good idea or not.

Automatically?  No, that'd be mostly a bad idea unless one were very
careful to limit the addresses that can be so bound to keys.  The
problem you get into is a DoS (unintentional even) where clients over
time cause all available dynamically assigned addresses to be so bound
to their keys in their peers' policy databases, which then denies new
clients that obtain those same addresses at future times the ability to
talk to those servers.

>                     Although it seems like the actual policy

Yes.

> to SPD? But I thought that's from _outside_ of IPsec such as

APIs are interfaces.  And yes, it would applications using them.
Anything from IPsec configuration apps (which shouldn't be necessary,
presumably, since you'd expect the native implementor to provide such
applications) to applications that wish to create policy given
contextual information (LoF at clients could be done this way).

Nico
--

---

From: nwnetworks at dial.pipex.com (Tom Petch)
Date: Fri, 24 Mar 2006 19:24:49 +0100

Not sure what gave rise to this thread but the security glossary draft
 <draft-shirey-secgloss-v2-04.txt>
now contains a definition which I would regard as a starting point

$ leap of faith
      1. (I) /general security/ Operating a system as though it began
      operation in a secure state, even though it cannot be proven that
      such a state was established (i.e., even though a security
      compromise might have occurred at or before the time when
      operation began).

      2. (I) /COMSEC/ The initial part, i.e., the first communication
      step or steps, of a protocol that is vulnerable to attack
      (especially a man-in-the-middle attack) during that part but, if
      that part is completed without being attacked, is subsequently not
      vulnerable in later steps (i.e., results in a secure communication
      association for which no man-in-the-middle attack is possible).

      Usage: This term is listed in English dictionaries, but their
      definitions are broad and can be interpreted in many ways in
      Internet contexts. Similarly, the definition stated here can be
      interpreted in several ways. Therefore, ISDs that use this term
      (especially ISDs that are protocol specifications) SHOULD state a
      more specific definition for it.

      Tutorial: In a protocol, a leap of faith typically consists of
      accepting a claim of peer identity, data origin, or data integrity
      without authenticating that claim. When a protocol includes such a
      step, the protocol might also be designed so that if a man-in-the-
      middle attack succeeds during the vulnerable first part, then the
      attacker must remain in the middle for all subsequent exchanges or
      else one of the legitimate parties will be able to detect the
      attack.

Tom Petch

----- Original Message -----
From: "Michael Richardson" <mcr at sandelman.ottawa.on.ca>
To: <anonsec at postel.org>
Sent: Monday, March 20, 2006 10:59 PM
Subject: [anonsec] what I call leap-of-faith

> ]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls
[
> ]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net
architect[
> ] mcr at xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device
driver[
> ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy");
[
> --=-=-=

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 27 Mar 2006 10:01:44 -0800

Nicolas Williams wrote:
> The better question is: where is the leap taken? 

By whatever enables BTNS, which would be a user or an app.

> If it's taken by the

Those PAD entries are instances of a broader "BTNS OK" entry, which
means the 'leap' has already been taken.

> what not over the latched connection.

Some servers have keys which don't match their DNS names, or are signed
by CAs which are not well-known (i.e., predistributed with the client
apps). In those cases, the client is sometimes asked to accept the key
for the session or permanently - which is the same leap that the server
takes w.r.t. the client (except that the server defaults to 'accept').

Joe

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 27 Mar 2006 12:14:18 -0600

> means the 'leap' has already been taken.

LoF isn't merely about accepting unauthenticated peers -- in the context
of SSH, for example, it's about interactively asking if a peer's public
key is "valid" and then recording it so that subsequently no such
interaction is necessary.

Applying the SSH model to BTNS we want:

 - "servers" to accept unauthenticated [BTNS] clients blindly, leaving
   it to the application to do any client/user authentication that might
   be desired at the application layer,

 - "clients" to require either that servers be authenticated (not BTNS)
   or that interaction with a user to accept a server's public key (BTNS
   PUBLICKEY ID) and record it somewhere (potentially the PAD could be
   used as an ssh_known_hosts type record, though I would not recommend
   it, and I would recommend against it on multi-user [time sharing]
   systems).

   Clients may, instead of interacting with a user to "validate" a
   server's public key, bind authentication at the application layer to
   the server's public key, as is done in SSHv2 with the GSS-API key
   exchange extension to SSHv2.

Nico
--

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 27 Mar 2006 10:35:44 -0800

> interaction is necessary.

This is the part I don't quite understand.

Where's the LOF?

	- accepting the key now
	- keeping it for later reuse

There's no reason the application can't set "accept unauthenticated
peers for the following addresses/protocols/ports", so that the protocol
doesn't need to ask the app even for new peers.

I.e., the 'leap' seems to be in 'blindly accepting a peer's cert'. That
need not wait for an initial exchange, and is often exactly what users
end up doing when asked anyway...

>    it, and I would recommend against it on multi-user [time sharing]

The key might be useful to record during the SA (to prevent hijacking),
but need not be recorded beyond that; the latter seems more like an
option than a necessity.

>    exchange extension to SSHv2.

The client must first auto-accept the server's public key (instead of
interacting with the user first), otherwise there won't be a channel to
bind later ;-)

Joe

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 27 Mar 2006 11:19:27 -0800

Here's a summary of what I understand so far; please post corrections.

1. leap of faith = accepting an unauthenticated certificate
	this refers to the FIRST accept of that certificate

	SSH servers do this automatically for client certificates, e.g.

	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.

2. caching previously 'trusted' (authenticated or LOF assumed) keys for
future use is NOT LOF
	there is no new leap taken

	this establishes continuity to _avoid_ a second LOF for the
	same certificate

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

Joe

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 27 Mar 2006 13:51:28 -0600

> This is the part I don't quite understand.

It's what we as human users to do: "validate" (as if they even usually
could, via some oob way) a peer's public key so that the application can
create a pseudonymous-ID-(public key)-to-peer-address/ID/name/... binding.

If unprotected traffic is OK then accepting peer public keys for "better
than nothing security" requires no "faith" at all.  (The BTNS core I-D
provides only for this, and so does not address LoF _at all_.)

OTOH, if protection against MITMs is required then on first meeting
either "faith" or channel binding will be required to get past a peer's
non-certified public key.

Once one has take this leep then one can create a

    public key -> name/address/ID

binding to avoid having to take it again later.

> doesn't need to ask the app even for new peers.

Yes, but that's not quite LoF.  And the app, given connection latching
and APIs to retrieve a latched connection's peer's public key, could
still do LoF at the app layer, even though there's no LoF below.

> end up doing when asked anyway...

Not just 'blindly accepting a peer's cert', but doing so when and in
spite of stronger authentication being desired, because one has "faith"
that one is not currently being actively attacked...

...And thence creating a stronger binding between the 'peer's cert' and
the name/address by which it was named (at the transport layer and below
that would always be an IP address; at the applications layers it would
be a name or address).

> interacting with the user first), otherwise there won't be a channel to

Yes, of course, and IPsec policy must allow it, but that's not LoF in
the SSH sense (see above); LoF in the SSH sense would consist of
recording a {server's public key, user-provided servername/address}
tuple on faith [that there peer really is the one the user wanted] and
subsequently using the recorded entry to avoid having to take the leap
again.

Nico
--

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 27 Mar 2006 14:47:36 -0600

On Mon, Mar 27, 2006 at 11:19:27AM -0800, Joe Touch wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

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

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

> 	this establishes continuity to _avoid_ a second LOF for the

(2) is incidental to LoF, but fundamental to making LoF practical.

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

Nico
--

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 27 Mar 2006 12:50:29 -0800

> create a pseudonymous-ID-(public key)-to-peer-address/ID/name/... binding.

That seems like a very specific thing - out-of-band validation. There's
no leap there - the user can (and seems like they're expected to)
validate the key out-of-band.

I.e., I was distinguishing between out-of-band validation - which is
what SSL clients tend to do when the server's key isn't signed by a
known CA, vs what SSL servers to - which does not involve asking a user
anything.

> non-certified public key.

There are different places in the communication that MITM can occur;
BTNS SAB still protects against MITM after the IKE DH step; it just
doesn't protect you from doing the DH with the middle-man. I.e., if the
DH isn't to the middle-man, then the stream should be MITM-protected.

> binding to avoid having to take it again later.

That step seems to have nothing to do with LOF or even CB. It seems like
it's just a local CA, equivalent to signing the remote keys yourself
(i.e., you trusted them before, so you trust them in the future).

> still do LoF at the app layer, even though there's no LoF below.

I didn't think LOF was limited to cases with connection latching; if it
is, please let me know.

> that one is not currently being actively attacked...

"blindly" meant 'in the absence of stronger authentication'

if stronger authentication is desired, the the leap isn't taken ;-)

the faith is that the attack isn't in the identity phase of the
protocol; there can still be assumptions of attacks at other phases
(e.g., data attacks)

> subsequently using the recorded entry to avoid having to take the leap

As per above, I don't see how using a cached leap is a new leap, and LOF
can't be defined in terms of just that cache (it'd be a circular
definition). There must be an initial leap; subsequent use of the cache
really seems like it isn't taking a new leap at all.

Joe

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 27 Mar 2006 12:57:57 -0800

>> 	SSH servers do this automatically for client certificates, e.g.

I meant client public keys. The auto-part is done at the server for the
client info.

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

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

> (2) is incidental to LoF, but fundamental to making LoF practical.

The only practicality relates to interrupting the user to do out-of-band
authentication. It's relevant only at the client side; the server side
need not cache anything to be practical.

> turn, provides a binding between individual packet flows and their

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.

Joe

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 27 Mar 2006 15:00:39 -0600

> validate the key out-of-band.

No, they usually can't, and even more commonly don't.  They take a
"leap": "I'm not being attacked"; and usually this leap works out fine
(which teaches them to keep this up).

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 27 Mar 2006 13:13:08 -0800

> (which teaches them to keep this up).

The leap's at the user level, NOT at SSL. SSL thinks the user is
performing whatever validation - leap or not - the user wants.

Besides, they can:
	- check to see if the cert has the IP address they expect
	- check to see if the cert has the DNS name they expect
	- check the contents of the cert (some websites of unsigned keys
	this info for this purpose, under the assumption that an
	attack would need to spoof both the web server and the SSH
	server to work)

Joe

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 27 Mar 2006 15:29:40 -0600

> I meant client public keys. The auto-part is done at the server for the

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.

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

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

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

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 27 Mar 2006 15:31:59 -0600

> performing whatever validation - leap or not - the user wants.

Huh?  Did you mean SSH?

> 	attack would need to spoof both the web server and the SSH

In the SSL/TLS case the leap really derives from installing and using
browsers with large sets of trust anchors :^/

In any case, if you have a cert that you can validate (up to an
acceptable trust anchor) and tie to the peer's address/name/whatever
then you're done, and there's no need to take leaps or bind channels.

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 27 Mar 2006 13:47:46 -0800

>> performing whatever validation - leap or not - the user wants.

I was talking about SSL (TLS). Which is probably why we got crossed
w.r.t. clients and servers. SSL/TLS is the one that has the server side
that is more like BTNS SAB, and the client side that is more like BTNS
w/channel binding.

> browsers with large sets of trust anchors :^/

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)

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 27 Mar 2006 16:30:50 -0600

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

b) Without interaction or creation of a persistent binding between a
   peer's public key and asserted identity LoF is no better than
   AUTH_SYS + unauthenticated DH key exchange;

c) Without interaction but with creation of a persistent binding between
   peer's public key and asserted identity LoF creates a DoS whereby
   peers can bottle up all scarce identities (in the BTNS case we've
   discussed that would be dynamically assigned IP addresses as well as
   any other addresses that an attacker can commandeer).

d) Creation of a persistent binding between a peer's public key and
   asserted identity is necessary for interactive LoF to be user-
   friendly and practical.

I'll also assert that:

 - draft-ietf-btns-core-00.txt does not address LoF at all, instead it
   provides for how to configure a system to allow unauthenticated peers
   for selected applications (selected based traffice selectors).

 - Connection latching + APIs to obtain a latched connection's peer
   ID/public key allows applications to implement channel binding and/or
   LoF at the application layer if they so desire.

 - The above + IPsec APIs such as Sam proposed would allow applications
   to drive LoF at the IPsec policy layer by creating PAD entries
   binding peer IDs/public keys to their addresses and creating
   associated SPD entries searched for by peer ID and binding specific
   traffic types to such PAD entries.

Comments?

Nico
--

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 27 Mar 2006 17:35:23 -0800

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

>    AUTH_SYS + unauthenticated DH key exchange;

I'm not sure I see your point here.

>    any other addresses that an attacker can commandeer).

If the certificate is kept, then there's a DOS attack. If it's not, then
there's no scarcity of identities to consume. That seems contrary to
your point here.

>    asserted identity is necessary for interactive LoF to be user-

I presented a case to the contrary of that before, e.g., SSH server-side
LOF.

> I'll also assert that:
> 
>  - draft-ietf-btns-core-00.txt does not address LoF at all,

This was a PAS issue...

>    LoF at the application layer if they so desire.

The issue w.r.t. the PAS doc is whether CL/CB are required for LOF or
not, and whether certificate caching is required for LOF or not. The
question I'm trying to resolve is more about whether LOF requires these
components - in which case it seems like it ought to be discussed solely
in the context of the CL/CB doc - or whether it's germane to the general
case, as discussed in the PAS.

Are there others who can help resolve this?

Joe

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 28 Mar 2006 02:16:21 -0600

> certificate presented without authentication.

We have to distinguish cases where we care not a bit about
authenticating peers or protecting traffice, in which case blindly
accepting peers and protecting traffic is "better than nothing," but not
remotely like SSH LoF.  We may argue about terminology, but when I think
LoF I think SSH (thanks to Michael for re-focusing the discussion on
that angle -- I was a bit lost before that).

> I'm not sure I see your point here.

AUTH_SYS is an ONC/RPC security flavour where clients assert their IDs
and servers do nothing particularly strong to verify that the clients
are who they say they are; and it provides no data protection.

> I presented a case to the contrary of that before, e.g., SSH server-side

No such thing.

> >  - draft-ietf-btns-core-00.txt does not address LoF at all,

LoF can be addressed in a separate I-D.  I saw no consensus for
describing LoF in the core doc.

> case, as discussed in the PAS.

Either could be followed, but the problems with the latter are such that
I will not pursue it.  (Feel free to edit an I-D that described the LoF
fotm you like :)

> Are there others who can help resolve this?

I hope so as for now we seem to be talking past each other (I attribute
this to a terminology problem :)

Nico
--

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 28 Mar 2006 07:21:21 -0800

Nicolas Williams wrote:
...
> describing LoF in the core doc.

Can someone else confirm this? If so, I'd be GLAD to remove it and call
the issue closed for now ;-)

Joe

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 28 Mar 2006 09:31:07 -0600

> the issue closed for now ;-)

:)

I do think though that now I understand what _I_ would want in terms of
LoF w/ BTNS, and how to specify it.

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Mon, 27 Mar 2006 16:49:29 -0500

>node addresses, though I wouldn't recommend it.

I agree that there may be a number of problems associated with LoF 
implemented at the IP layer, as Nico noted.  I also want to second 
Nico's aversion to using
  APIs for manipulating the PAD or SPD as a way to address all of our problems.

IPsec focuses on access control that is effected via these databases. 
If every app can manipulate these databases, then we undermine these 
access controls.  A Trojan Horse acting on these databases via an API 
could completely circumvent whatever policy a user might have 
established. To avoid this sort of problem we would have to impose 
access controls on what SPD/PAD entries different apps are allowed to 
manipulate, which sounds awfully complex.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 28 Mar 2006 02:09:24 -0600

>  APIs for manipulating the PAD or SPD as a way to address all of our 

Oh, I'm not entirely averse to them, I'm averse to automatically
creating PAD/SPD entries corresponding to BTNS peers one has seen,
because of those problems.  LoF should be implemented, if at all, at the
app layer using connection latching and APIs to retreive the latched
IDs/keys.

Nico
--