[anonsec] comments on the BTNS core I-D

[Michael Richardson]

Stephen Kent wrote:
> easily visible.  I then convert to a PDF, so everyone can read the 
> results, and still see the changes.  As someone who does not 
> regularly use Unix for text editing, I don't find diff's helpful, 
> something reaffirmed by looking at the diff you provided at the end 
> of this message :-).

   I understand. For those of us who do use it, it is very immediately
visible what is going on, and there are some who can apply diffs in their head.

>> We think that the the only things that matters is that
>> [C] can't assert [Q]'s identity, or [B]'s identity, because those IDs are in
>> the PAD as non-BTNS, and therefore [SG-A] must have some way to positively
>> identify those nodes public keys. So, C can't assert itself as being [C] or
                                                                         [B]
>> [Q] without the appropriate private key. That's standard IPsec processing.

>>
>> Was that your concern? Or something else.
>>
> 
> my comment appears on page 7, in reference to example #1. I asked the 
> question because the PAD description in 4301 says how to search the 
> PAD based on matching the ID asserted in IKE against the PAD. there 
> are words early in this document (page 4) about the new ID type 
> "PUBLICKEY" and the need to coerce the ID offered by a BTNS peer into 
> this new ID type, which is never transferred over the wire via IKE. 
> (That raises the question of whether we ought to describe this as an 
> IKE ID type, but I'll let Charlue Kaufman comment on that later, if 
> he wishes.)

   The public key *is* transmitted on the wire in a slightly mis-named "CERT" 
payload, of type "Raw RSA Key                         11". This was first 
stated on page 4 of btns-core, (and page 59 of RFC2406).

> 	- If the ID asserted by a peer does not match any PAD entry, 
> then a BTNS-enabled IPsec implementation replaces the ID with into 
> the new ID of type "PUBLICKEY" that is created by extracting the 
> public key from the IKE CERT (or ??) payload
> 
> 	- the PAD is searched again, using this new ID type and value
> 
> 	- if there is a match, the associated PAD entry (which will 
> be a BTNS entry) is used to control the SPD search
> 
> 	- if there is no match, the IKE SA is rejected

Good text. We'll use it.
Q: does this relax the requirement for the PAD entry to be lowest priority?
The two searches can be implemented with a single scan, with a priority based 
comparison (i.e. keep on the best match).