[anonsec] what I call leap-of-faith

Hi, Michael,

Comments below.

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

Joe Touch

2006-03-23 22:36:32 UTC

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

Post by Yu-Shun Wang
Hi, Michael,
Comments below.

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

Disagree on the last point, though it's subtle and not sure
how significant it'll be. When SSH stores the key from the
- 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
_______________________________________________

Nicolas Williams

2006-03-23 22:57:45 UTC

Post by Joe Touch
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
- accepting the first UC
- assuming that matching UCs mean matching endpoints
- somewhere else?

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

Joe Touch

2006-03-27 18:01:44 UTC

The better question is: where is the leap taken?

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

Post by Nicolas Williams
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.

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

Post by Nicolas Williams
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.

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

Nicolas Williams

2006-03-27 18:14:18 UTC

The better question is: where is the leap taken?

By whatever enables BTNS, which would be a user or an app.
[...]
Those PAD entries are instances of a broader "BTNS OK" entry, which
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
--

Joe Touch

2006-03-27 18:35:44 UTC

The better question is: where is the leap taken?

By whatever enables BTNS, which would be a user or an app.
[...]
Those PAD entries are instances of a broader "BTNS OK" entry, which
means the 'leap' has already been taken.

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

Post by Nicolas Williams
- "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).

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.

Post by Nicolas Williams
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.

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

Nicolas Williams

2006-03-27 19:51:28 UTC

Post by Nicolas Williams
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.

This is the part I don't quite understand.
Where's the LOF?

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.

Post by Joe Touch
- 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.

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.

Post by Joe Touch
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...

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

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

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

Joe Touch

2006-03-27 20:50:29 UTC

This is the part I don't quite understand.
Where's the LOF?

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.

Post by Nicolas Williams
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.

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.

Post by Nicolas Williams
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.

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

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

Post by Joe Touch
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...

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

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

Post by Nicolas Williams
...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).

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

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

Nicolas Williams

2006-03-27 21:00:39 UTC

This is the part I don't quite understand.
Where's the LOF?

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.

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

Joe Touch

2006-03-27 21:13:08 UTC

This is the part I don't quite understand.
Where's the LOF?

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.

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

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

Nicolas Williams

2006-03-27 21:31:59 UTC

Post by Joe Touch
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.

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

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

Huh? Did you mean SSH?

Post by Joe Touch
- 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)

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.

Joe Touch

2006-03-27 21:47:46 UTC

Post by Joe Touch
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.

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

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

Huh? Did you mean SSH?

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.

In the SSL/TLS case the leap really derives from installing and using
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)

Post by Nicolas Williams
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.

Nicolas Williams

2006-03-27 22:30:50 UTC

Post by Joe Touch
- 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";

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

Joe Touch

2006-03-28 01:35:23 UTC

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.

Post by Nicolas Williams
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;

I'm not sure I see your point here.

Post by Nicolas Williams
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).

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.

Post by Nicolas Williams
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 presented a case to the contrary of that before, e.g., SSH server-side
LOF.

Post by Nicolas Williams
- draft-ietf-btns-core-00.txt does not address LoF at all,

This was a PAS issue...

Post by Nicolas Williams
- 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 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

Nicolas Williams

2006-03-28 08:16:21 UTC

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.

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.

Post by Nicolas Williams
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 presented a case to the contrary of that before, e.g., SSH server-side
LOF.

No such thing.

Post by Nicolas Williams
- draft-ietf-btns-core-00.txt does not address LoF at all,

This was a PAS issue...

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

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

Post by Joe Touch
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
--

Joe Touch

2006-03-28 15:21:21 UTC

Nicolas Williams wrote:
...

Post by Joe Touch
This was a PAS issue...

LoF can be addressed in a separate I-D. I saw no consensus for
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

Nicolas Williams

2006-03-28 15:31:07 UTC

Post by Joe Touch
...

Post by Joe Touch
This was a PAS issue...

LoF can be addressed in a separate I-D. I saw no consensus for
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 ;-)

:)

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

Nico
--

Stephen Kent

2006-04-03 21:52:41 UTC

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

Nicolas Williams

2006-04-04 14:53:29 UTC

Post by Nicolas Williams
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.

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

Post by Stephen Kent
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.

Post by Stephen Kent
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
--

Stephen Kent

2006-04-04 17:14:00 UTC

Nico,

Post by Nicolas Williams
...

Post by Stephen Kent
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.

Post by Nicolas Williams
I *much* prefer the second method.

no argument from me.

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

Post by Nicolas Williams
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.

Post by Nicolas Williams
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.

Post by Nicolas Williams
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

Nicolas Williams

2006-04-04 18:05:36 UTC

Post by Stephen Kent
Nico,

Post by Nicolas Williams
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.

More violent agreement.

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.

Post by Nicolas Williams
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.

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

Pekka Nikander

2006-04-10 10:04:30 UTC

Steve and Nico,

Post by Stephen Kent
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.

Post by Nicolas Williams
I *much* prefer the second method.

no argument from me.

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.

Post by Stephen Kent
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 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.

Post by Nicolas Williams
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 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

Michael Richardson

2006-04-21 19:48:12 UTC

Joe Touch

2006-03-27 19:19:27 UTC

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

Nicolas Williams

2006-03-27 20:47:36 UTC

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

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.

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

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

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.

Nico
--

Joe Touch

2006-03-27 20:57:57 UTC

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.

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

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.

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

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

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

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

Nicolas Williams

2006-03-27 21:29:40 UTC

Post by Nicolas Williams
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.

Post by Joe Touch
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.

Post by Joe Touch
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.

Post by Joe Touch
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.

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

Post by Joe Touch
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?).

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

Michael Richardson

2006-04-21 19:43:00 UTC

Nicolas Williams

2006-03-23 23:47:13 UTC

Post by Yu-Shun Wang
Finally, I am not sure if adding SPD entries because of BTNS is
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.

Post by Yu-Shun Wang
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?

Yes.

Post by Yu-Shun Wang
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.

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

Tero Kivinen

2006-03-23 17:25:44 UTC

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

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.

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

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.

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)

--
kivinen at safenet-inc.com

Nicolas Williams

2006-03-23 17:46:21 UTC

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

Stephen Kent

2006-03-27 21:49:29 UTC

Post by Nicolas Williams
...
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

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

Nicolas Williams

2006-03-28 08:09:24 UTC

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

Nicolas Williams

2006-03-23 23:42:01 UTC

The leap-of-faith is that the user is consulted as an oracle to make the hard
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
authentication when the host is not yet known, to avoid disclosing the
password to a MITM.

Yup.

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.

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

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.

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

I see no major problem with storing the keys by other IDs, particularly
random DN.

Or whatever name a user passed to the client UI.

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

Tom Petch

2006-03-24 18:24:49 UTC