Re: core doc outstanding issues

At 8:47 AM -0600 2/21/07, Nicolas Williams wrote:
>On Wed, Feb 21, 2007 at 09:22:02AM -0500, Stephen Kent wrote:
>>  At 12:30 PM -0600 2/20/07, Nicolas Williams wrote:
>>  >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.

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?

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

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