Subject: [anonsec] applicability

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 6 Jun 2005 14:09:54 -0500

If we step back from Joe's and Stephen's recent discussion, just what is
the applicability of BTNS?

Here's something to start with, and let's see what we can build up from
there:

 - BTNS can provide protection against passive attacks.  This is weak,
   but, as the expansion of 'BTNS' says, "better than nothing."

 - BTNS can help pre-share public keys (and certs).  "Connect to
   somehost, then call me and we'll verify the hashes of each other's
   public keys."

 - BTNS can provide IDs suitable as material for channel bindings at
   higher layers without requiring deployment of an authentication
   infrastructure for IPsec (no need to pre-share keys, certs; no need
   for PKI, or Kerberos V).

 - Anything else?

Anyways, whether or not the better-than-nothing protection against
passive attacks turns out to be of any practical utility to router
administrators, clearly it may yet have uses elsewhere.  (The WG
charter, BTW, does not even mention routers or BGP.)

Ideally the better-than-nothing aspect of BTNS will asymptotically
disappear in that we'll all deploy authentication infrastructures or
otherwise find suitable ways of exchanging key material :)

And if that ideal is at all achievable (and I don't mean to suggest that
it is) then BTNS' namesake use is fundamentally a short-term feature, a
band-aid.

Perhaps this is why I've never felt strongly about Joe's primary BTNS
use case and focused instead on the channel bindings aspect of BTNS, or
perhaps that's just because that's what I've wanted to have since before
that ANONSEC BoF.

Be that as it may, I'd like to see some applicability I-D text ;)

Cheers,

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 9 Jun 2005 11:26:38 -0400

>the applicability of BTNS?

good change of topic :-)

>    but, as the expansion of 'BTNS' says, "better than nothing."

OK

>    somehost, then call me and we'll verify the hashes of each other's

OK, but this implies that we mandate management interfaces that 
support this capability, not just the changes to the PAD and/or SPD 
syntax that have been discussed.

>    infrastructure for IPsec (no need to pre-share keys, certs; no need

this needs more detail to explain the contexts in which this is 
expected to work, what sort of APIs have have to be created or 
augmented to support it, etc. (recall that PF_KEY is not a standard, 
just an informational RFC.) a clear statement of the problem being 
addressed here is needed.

>...

like the temporary wooden buildings constructed at MIT for work on 
radar, that persisted for about 50 years :-)

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 9 Jun 2005 14:49:04 -0500

> syntax that have been discussed.

But this could be optional, and we don't have to get too specific about
those interfaces.

> addressed here is needed.

Yup.  That's mentioned in the charter, under item (e).

> radar, that persisted for about 50 years :-)

Perhaps :/

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 9 Jun 2005 17:45:10 -0400

Nico,

>But this could be optional, and we don't have to get too specific about

If can be optional in the same sense that PAD/SPD changes are 
optional for those who want to support BTNS functionality. but if we 
don't define such interfaces then it's not fair to cite this 
functionality as a context where BTNS is applicable.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 9 Jun 2005 17:02:15 -0500

> functionality as a context where BTNS is applicable.

I used "optional" in response to your use of "mandate" -- I meant to
clarify that BTNS implementors wouldn't be required to implement such
interfaces if they chose not to implement the optional feature that
requires them.  Whereas the PAD/SPD changes might well be a fundamental
aspect of BTNS and therefore not at all optional for BTNS implementors

Must we quibble over the meaning of every sentence we each utter?  By
now I'm pretty sure we all know what we each mean by "anonymous" or
"unauthenticated" on this list, for example, yet it seems that every
time someone uses one or the other of those we argue over what they
mean.  I'd rather get beyond that.

Cheers,

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 9 Jun 2005 18:32:16 -0400

Nico,

>aspect of BTNS and therefore not at all optional for BTNS implementors

If you choose to make the PAD/SPD changes a mandatory part of BTNS, 
but do not require the sort of management interface we were 
discussing, that's fine. But then you ought not cite an scenario as a 
supporting application context for BTNS in general, because BTNS in 
general will not be guaranteed to provide the required support. So, 
when I said mandate, I meant exactly that.

>mean.  I'd rather get beyond that.

Words are important. If we don't use appropriate terminology, we will 
argue about this for a long time, we will confuse folks who read the 
documents and were not part of the WG, etc.

As for "anonymous" vs. "unauthenticated" if you review the list 
traffic, Joe was almost alone in his insistence that the former term 
was appropriate. Most folks, not just me, argued against his use of 
the term in this context, according to my tally of the messages.

I have spent over 25 years working in the network security area. I am 
generally considered to be very articulate, both in writing and in 
speech. Joe, on the other hand, is well known as being very 
inarticulate, unable to express what may be good ideas, in writing or 
speech.  So, if you want to choose sides on the question of what is 
or is not a good way to articulate your ideas, characterize the 
problem being solved, etc. you might want to think twice about who's 
advice you should take.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 9 Jun 2005 17:54:35 -0500

You lost the context, which was:

> > Nico>  - BTNS can help pre-share public keys (and certs).  "Connect to
> > Nico>    somehost, then call me and we'll verify the hashes of each
> > Nico>    other's
> > Nico>    public keys."
> > 
> Steve> OK, but this implies that we mandate management interfaces that 
> Steve> support this capability, not just the changes to the PAD and/or SPD 
> Steve> syntax that have been discussed.
> 
Nico> But this could be optional, and we don't have to get too specific about
Nico> those interfaces.

You were commenting on something that had hitherto not been a core part
of BTNS.

> documents and were not part of the WG, etc.

See my other reply to you on this.

Nico
--