Subject: [anonsec] BTNS and CERT, CERTREQ payloads

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 3 Oct 2005 12:21:50 -0500

Observations:

 - CERT payloads are optional and CERTREQ payloads must deliver trust
   anchors.

So what is a BTNS-only node to do when another node fails to send a
CERT?

IMO, fail as the other node wouldn't have accepted the first's ephemeral
CERT anyways.

If the matching SPD rule for a given SA proposal allows for BTNS then
the node MUST send a CERT payload.

A separate but related concern:  when should a node use an ephemeral
credential if it has certs that are acceptable to other non-BTNS nodes?

Using ephemeral credentials may have some value, I suppose (privacy?).

It seems we may need an ID selector value for the local ID in SPD rules
that matches ephemeral credentials ony, in addition to the remote ID
selector value already specified in the -00.

Nico
--

---

From: jari.arkko at piuha.net (Jari Arkko)
Date: Mon, 03 Oct 2005 21:42:00 +0300

>IMO, fail as the other node wouldn't have accepted the first's ephemeral
Yes. But I guess the primary reason for that would be that
you do not have a public key, and you can't complete the
initial authentication.

>the node MUST send a CERT payload.
I think so. Is there a difference wrt initiator and responder
behaviour here? Can a rule allow both BTNS and non-BTNS
at the same time?

>selector value already specified in the -00.
I think so.

--Jari

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 3 Oct 2005 15:16:17 -0500

> you do not have a public key, and you can't complete the

One that the other node would trust, yes.

> behaviour here? Can a rule allow both BTNS and non-BTNS

Yes, an SPD/PAD rule might have the node might use a non-BTNS credential
(i.e., a calid cert in some large PKI) while treating the peer as BTNS
-- i.e., the peer may use a cert from the same PKI, or an ephemeral one
and either will work.

So, I think that we need new special ID selector values for local and
remote IDs.  The remote ID selector value is already specified in the
I-D: 'UNKNOWN'.  The local ID selector value for selecting an ephemeral
self-signed certificate might be called 'EPHEMERAL', 'BTNS',
'ANONYMOUS'[*] or something of the sort.

For the local ID selector, do we wish to distinguish between a
self-signed cert generated at boot time (or periodically) vs. one
generated for each SA negotiation?

[*]  Oh no, not that discussion again :)

> >selector value already specified in the -00.

Thanks,

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Tue, 4 Oct 2005 10:11:34 -0400

At 9:42 PM +0300 10/3/05, Jari Arkko wrote:
>behaviour here?

as currently defined, the PAD specifies the authentication and 
authorization info for a peer irrespective of whether the peer is the 
initiator or the responder.

>Can a rule allow both BTNS and non-BTNS
>at the same time?

In earlier discussions I had suggested marking a PAD rule as 
applicable to BTNS vs. current IPsec modes of use. the notion was 
that the scope of IDs that a BTNS peer could assert had to be 
disjoint from any asserted by a non-BTNS peer, for access control 
purposes.  if a peer could be either, this simple rule can't be 
applied, and that may cause problems with our requirement to not 
impinge on existing Ipsec access controls when BTNS is enabled.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 4 Oct 2005 13:01:09 -0500

On Tue, Oct 04, 2005 at 10:11:34AM -0400, Stephen Kent wrote:
> purposes.

SPD/PAD entries that allow for BTNS peers also must allow for non-BTNS
peers, the whole point being that their IDs and credentials are not
important in the context of such entries.

>            if a peer could be either, this simple rule can't be 

I don't see how that how that follows.

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Tue, 4 Oct 2005 21:34:30 -0400

>important in the context of such entries.

I have not yet read the latest rev of your I-D so maybe that explains 
this issue clearly, but I am confused. Is the intent to allow 
creation of either an authenticated or an unauthenticated SA with the 
same peer? How are we planning to identify such peers? For an 
authenticated peer we employ an ID that has been coordinated with the 
peer, or a rep thereof, either a specific ID or a structured name 
that fits with the naming scope of a CA that has been specified for 
the PAD entry. It would seem difficult to make a meaningful PAD entry 
a priori for an unauthenticated peer, based on any of the 6 types of 
IDs defined for PAD entries in 2401bis, but maybe you can provide 
some scenarios that are compatible with that notion. Also, once I 
have a way to authenticate a peer, why would I choose to create a 
BTNS SA?

>I don't see how that how that follows.

If I have a PAD entry for a peer and the peer can either be 
authenticated or not, then the rule I proposed months ago needs 
further conditions. Otherwise the entry would conflict with itself, 
i.e., when viewed as a BTNS peer the ID asserted would conflict with 
the same entry when viewed as an authenticated peer.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 4 Oct 2005 20:42:30 -0500

> the same entry when viewed as an authenticated peer.

Right, but think of the PAD and SPD together.  The PAD may say that the
peer at a given IP address (or address range, or whatever) needs to be
authenticated with a credential from some PKI, but an SPD entry may say
that BTNS peers are OK.  The PAD and SPD together then would allow
either that peer to use only non-BTNS credentials but be treated as a
BTNS peer, or to use any credentials and be treated as a BTNS peer.

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Wed, 5 Oct 2005 07:40:41 -0400

>BTNS peer, or to use any credentials and be treated as a BTNS peer.

I think it important to speak about the PAD and the SPD distinctly, 
to avoid confusion, even though the two are used together to support 
access control decisions.

I agree that an SPD entry could be marked to says that BTNS peers are 
OK, as you have suggested in the past, but we also need to be 
explicit about whether this is just a one-bit status indicator, or if 
we need two bits to represent all the interesting states, i.e., 
BTNS-only, authenticated-only (the current, implicit status), or both 
are OK.

The text above makes one set of assumptions about what is OK re 
relating entries from the PAD and the SPD, but are we sure that this 
is the only appropriate relationship?

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 5 Oct 2005 09:56:10 -0500

> BTNS-only, authenticated-only (the current, implicit status), or both 

When an SPD entry says "BTNS peers are OK" it has got to mean "whatever
their credentials, whether authenticated or otherwise."

Why should a peer get penalized for using what would have been a valid
credential if the SPD entry says BTNS is OK.  How could it have known a
priori (we assume no on-the-wire changes to IKEv2) that it should use a
BTNS credential?

Nico
--