Subject: [anonsec] core doc outstanding issues

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Sun, 18 Feb 2007 22:39:06 -0600

At IETF66 there was one substantial comment made on
draft-ietf-btns-core-01.

It was a comment by Stephen Kent about an inconsistency in the PAD
tables given in the examples.

You can find Stephen's comment at 45:50 and 58:40 in the recording of
the meeting[1].  Roughly, it went like this:

   "I was just going to look it up in RFC4301, but I was surprised in
    the previous slide [the PAD in example 1] that you had child SAs
    constrained by network addresses but then said we were doing SPD
    searches by ID, that's not what occurs to me as the combination of
    things we'd have there, but I was going to go back and check the
    spec to see."

I seemed to understand what he meant, but I've since lost that
understanding.  So I've listened to the recording of the meeting and
re-read section 4.4.3 of RFC4301 (the one that deals with the PAD) and I
can't figure out what Stephen meant or what I'd understood.

Specifically I cannot find text in RFC4301, section 4.4.3, that states
that the "search SPD by" field of a PAD entry must be correlated with
anything else about the PAD entry.

Perhaps what Stephen meant was that in our examples we conflated the
symbolic name and remote traffic selector fields of the SPD?  We did
that on purpose to keep the example tables _small_ and legible, but
perhaps this merits a note in the text of the I-D, or perhaps we should
just have separate columns for this.

Once we resolve this I think we can request a WGLC (or perhaps resolve
this during a WGLC?).

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Tue, 20 Feb 2007 09:26:13 -0500

>     things we'd have there, but I was going to go back and check the

4301 introduced the PAD as a way to ensure that after peer IKE entity 
was authenticated, it was not allowed to make unconstrained 
assertions about the set of users that it represented. The PAD 
provides two ways to impose constraints on what an IKE entity can 
assert when it negotiates to create SAs:
	- IDs asserts via the IKE ID
	- it can impose constraints on the addresses asserted as 
traffic selectors

The relevant text in 4301 is:

"Each entry also specifies whether the IKE ID payload will be used as 
a symbolic name for SPD lookup, or whether the remote IP address 
provided in traffic selector payloads will be used for SPD lookups 
when child SAs are created."

You have indicated that the example PAD (on the slide in question) was:

                                 Child SA
          Rule Remote ID        IDs allowed  SPD Search by
          ---- ---------        -----------  -------------
           1   <B's ID>          <B's network>  ID
           2   <Q's ID>          <Q's host>     ID
           3   PUBLICKEY:any     ANY            by-IP

I still find this a somewhat confusing table. For example, in entry 
#1 it seems to say that the PAD says search by ID, but it also says 
that child SAs are to be allowed based on "B's network." The 4301 
text quoted above provides an exclusive OR option for how to 
constrain SPD searches, i.e., you either constrain IDs or addresses, 
so why are there two columns, one for "Child SA ID's allowed" and one 
for "SPD Search by?" Also, what is an example of an ID (vs. an 
address) for "B's network?" In 4301 names are defined in 4.4.1.1 and 
none of the defined name types refers to a network, per se, as 
opposed to a machine or a person. So there is some ambiguity here. I 
think we need a table that is more easily mapped to the PAD 
description in 4301 so as to avoid the sort of ambiguities that I 
note here, and that I assume prompted my comments during the BTNS 
meeting.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 20 Feb 2007 12:30:26 -0600

On Tue, Feb 20, 2007 at 09:26:13AM -0500, Stephen Kent wrote:
> that child SAs are to be allowed based on "B's network."

OK, I see that for rules #1 and #2 we should probably search the SPD by
IP address (because SPD searching by name is intended for road warriors,
which Q and B clearly are not).  But I don't think it's actually wrong
to search it by peer IP address in those two cases either.

I also see that searching the SPD by ID in the case of entry 3, and
having wildcard matching in the SPD, would also help simplify writing
the SPD.

>                                                          The 4301 
> for "SPD Search by?"

I don't see how the text you quoted says this.

I read the RFC4301 section 4.4.3 text as saying that PAD entries are
obtained by matching against the peer ID and then the matched PAD entry
constrains the peer's TSes and specifies how to search the SPD -- but I
see no correlation betwee those two items (constraints on peer TSes and
how to search the SPD).

>                      Also, what is an example of an ID (vs. an 
> opposed to a machine or a person. So there is some ambiguity here.

Huh?  RFC4301, section 4.4.1.1 lists these types of SPD symbolic names
for when searching the SPD by ID:

|        For case 1, responder, the identifiers employed in named SPD
|        entries are one of the following four types:
|
|                a. a fully qualified user name string (email), e.g.,
|                   mozart at foo.example.com
|                   (this corresponds to ID_RFC822_ADDR in IKEv2)
|
|                b. a fully qualified DNS name, e.g.,
|                   foo.example.com
|                   (this corresponds to ID_FQDN in IKEv2)
|
|                c. X.500 distinguished name, e.g., [WaKiHo97],
|                   CN = Stephen T. Kent, O = BBN Technologies,
|                   SP = MA, C = US
|                   (this corresponds to ID_DER_ASN1_DN in IKEv2, after
|                   decoding)
|
|                d. a byte string
|                   (this corresponds to Key_ID in IKEv2)

>                                                                    I 

It would help to have a more formal description of the PAD.

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Wed, 21 Feb 2007 09:22:02 -0500

At 12:30 PM -0600 2/20/07, Nicolas Williams wrote:
>...as:

If you want to use a peer's IP address in the search, then  you 
should mark the PAD entry to indicate search by address vs. search by 
ID and then set the address constraints part of the PAD entry 
appropriately. That is accommodated by the text in 4301; I just noted 
that the table in the example is inconsistent.

>having wildcard matching in the SPD, would also help simplify writing

I didn't comment on entry #3. It it clearly designed to allow any 
public key to be acceptable, which is OK for a last entry in a system 
supporting BTNS-style authorization. The next column in the table 
says ANY, which means any address, given that the third column says 
search by IP address. That is consistent too, so I see no problem 
with this PAD entry example.  The SPD does allow wildcard matching, 
via the ANY construct for IP addresses, which is what this entry 
calls for, so I'm not sure what you're getting at here?

>see no correlation betwee those two items (constraints on peer TSes and

Sorry for being a bit sloppy in my text above. Section 4.4.4.3 says 
that one can use either the IKE ID for SPD searches by name, OR one 
can use the traffic selector addresses for SPD searches. So the first 
part of what i said above is clearly correct. However, my comment 
about the two columns in the example is off the mark.

>|                   (this corresponds to Key_ID in IKEv2)

yes, these are the name types in 4301 that IU was referring to. It 
seems clear that "a" and "b" are not names for networks. I'd argue 
that "c" is also not generally thought of as a name type to be used 
to spevcify a network.  So, that leaves only "d" which is a name for 
a key, and I also don't think of that as a name for a network.  So, 
my observation still stands.

>  > I think we need a table that is more easily mapped to the PAD

yes, that could help, but I think I've pointed to text in 4301 that 
shows why the example on the slide was not a good one.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 21 Feb 2007 08:47:16 -0600

> shows why the example on the slide was not a good one.

Not a good one, perhaps, but not incorrect either (below I think out
loud to convince myself that it's not a good example).  As I explained
at the meeting at IETF66 one might prefer to to use names instead of
TSes for SPD searches if referential integrity between the PAD and the
SPD using IP addresses is harder to maintain than using IDs -- which it
might well be.

I'll make the following changes to the I-D and submit:

 - change those example PAD entries (all non-BTNS ones) to search the
   SPD by IP address

 - change the example SPDs to have a separate column for name, if I
   still have any PAD entries specifying tha the SPD be searched by ID

 - add a better description of how the whole PAD constrains the TSes
   that BTNS peers can assert for their child SAs

Now for the thinking out loud...

Suppose we use certs with iPAddress SANs, then the PAD can be very
simple, and the SPD can be very simple also, with only the PAD
mentioning any IP addresses, if at all, and if it does then only,
perhaps, to deal with lack of suitable name constraints in the relevant
CA certs.

The first thought that comes to mind is that given such certs and peers
that assert such IDs and nodes that enforce iPAddress == peer IP address
(modulo NAT) then there is no real distinction between searching the SPD
by peer ID or by peer IP!

Also, RFC4301 section 4.4.1.1 does not mention iPAddress SANs, but is
that an omission? or are FQDNs really sufficient?  And are there
real-world deployments of PKIs that support iPAddress SANs and matching
name constraints?  And why would there be any if IPsec didn't support
iPAddress SANs (well, RFC4301 doesn't mention them AFAICS)?

Cheers,

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Wed, 28 Feb 2007 22:25:28 -0500

>perhaps, to deal with lack of suitable name constraints in the relevant

Is the idea that a CA will issue certs where each one has an 
IPaddress as a SAN, and the PAD will say "if you can verify the cert 
using this trust anchor, then it's OK; perform the SPD entry search 
using the SAN value (which happens to be an address in this case)? 
You suggest that one motivation for issuing such certs may be a 
problem getting suitable name constraints in certs issued by this CA. 
So, I assume the intent here is to construct PAD entries that achieve 
the effect of the missing name constraints, as applied to the IP 
address SAN, right?

>by peer ID or by peer IP!

Your are right that in this case the two forms of searching might be 
equivalent, if the SPD allowed use of names that were IP addresses, 
but the SPD makes no provision to use an IPaddress as a name. Page 29 
describes the four name types allowed, and IPaddresses are notably 
absent.

>iPAddress SANs (well, RFC4301 doesn't mention them AFAICS)?

4.4.1.1 says that the use of names for responder lookups in the SPD 
is designed to accommodate circumstances where use of the address 
from the initiator's IP address would not be appropriate for a 
lookup, e.g., because it might not be determinable in advance. The 
example you gave is one where the address is known in advance, since 
you described putting it in a cert, but that means the example does 
not fit the notion that motivates support for name-based searches of 
the SPD by a responder.

So, the question is whether this example is sufficiently compelling 
to warrant a change to the PAD and SPD text too accommodate it. Also, 
we need to note that this is not intended to be used by SGs, just by 
individual hosts, right?

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 28 Feb 2007 22:26:42 -0600

> we need to note that this is not intended to be used by SGs, just by 

No, it's not sufficiently compelling -- as I wrote, that was a stream of
consciousness whereby I convinced myself that the example in our I-D was
not a good one.  It sufficed to have validation of that thought process;
answers to the additional questions therein would be a plus, but not
necessary.

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 28 Feb 2007 22:44:16 -0600

BTW, I've submitted a new version of btns-core.  And also a new version
of btns-connection-latching.