Subject: [anonsec] IKE, PAD, SPD extensions, take 2

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Sun, 7 Aug 2005 15:14:22 -0500

So, Charlie Kaufman and I chatted after the meeting, and he convinced me
that we need no IKE extensions.

Basically, whether a peer takes one to be authenticated as one's
asserted ID or not doesn't seem to be very important (except of course
for authorization decisions made by that peer).

This means that for BTNS hosts should use whatever credentials, or
ephemeral self-signed tickets that they wish.

Not having BTNS-specific bits on the wire in IKE makes analyzing the
protocol simpler, particularly with regard to assymetric cases.

That leaves us with the PAD/SPD extensions.

We talked about it and concluded that all we really need is, almost
anyways, the ANY wildcard value for ID selectors.  I say "almost"
because ANY in existing deployments could be taken to mean "any peer
with certs I can validate with my configured trust anchors" so that
chaning ANY to mean "any peer, BTNS or otherwise" would be rather, er,
rude.

So we need a new ID selector wildcard value corresponding to 'truly
ANY'.

What to name that value?

Nico
--

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Sun, 7 Aug 2005 17:02:20 -0500

I'll re-write my -00 thusly and resubmit.

Nico
--

---

From: pekka.nikander at nomadiclab.com (Pekka Nikander)
Date: Mon, 8 Aug 2005 09:51:15 +0200

> [...]

UNKNOWN?  If the current semantics of ANY is basically "any whose
identity I can assert w.r.t. to some trust anchor", won't this new
"ANY" be "any whose identity I can't assert", i.e., unknown?

--Pekka

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 8 Aug 2005 10:07:33 -0500

> "ANY" be "any whose identity I can't assert", i.e., unknown?

Perfect.  Thanks.

Look for an I-D in a few days.

Nico
--

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 8 Aug 2005 16:08:27 -0500

> > "ANY" be "any whose identity I can't assert", i.e., unknown?

We still have to consider how to represent opportunistic BTNS, that is
"if the peer can do IKE, use BTNS, else don't use IPsec at all."

I haven't given this any thought beyond noting that there's a downgrade
attack through denying IKE service.

Nico
--

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 09 Aug 2005 13:21:50 -0700

> "ANY" be "any whose identity I can't assert", i.e., unknown?

I'd have gone with "NONE", in the sense that it isn't even relevant.
UNKNOWN sounds more like something that should generate an error
somewhere (i.e., it implies erroneous operation).

Joe