[anonsec] core doc outstanding issues

[Nicolas Williams]

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

[Stephen Kent]

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

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

[Nicolas Williams]

Post by Stephen Kent

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

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
- IDs asserts via the IKE ID
- it can impose constraints on the addresses asserted as
traffic selectors
"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."
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."

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.

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

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

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

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)

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

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

Nico
--

[Stephen Kent]

Post by Nicolas Williams

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

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.

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.

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

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?

Post by Nicolas Williams

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

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

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.

Post by Nicolas Williams

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

Huh? RFC4301, section 4.4.1.1 lists these types of SPD symbolic names
| For case 1, responder, the identifiers employed in named SPD
|
| 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)

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.

Post by Nicolas Williams

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

It would help to have a more formal description of 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

[Nicolas Williams]

Post by Stephen Kent

Post by Nicolas Williams
It would help to have a more formal description of 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.

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

[Stephen Kent]

Post by Nicolas Williams

Post by Stephen Kent

Post by Nicolas Williams
It would help to have a more formal description of 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.

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

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?

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

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.

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

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

[Nicolas Williams]

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

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.

[Nicolas Williams]

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