[anonsec] comments on the BTNS core I-D

[kent at bbn.com (Stephen Kent)]

At 12:20 AM -0500 7/26/07, Michael Richardson wrote:
>Stephen Kent wrote:
>>  Sorry I didn't get these out sooner.
>
>thank you very much.
>
>Nico and I printed your PDF and worked with it from 4pm to 9pm tonight.
>(diff -u output would have been much easier to deal with)

sorry. I always import the text version of an I-D into MS Word, where 
I can mark it up and add comments and have both sorts of changes be 
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 :-).

>...
>The only thing we didn't resolve was your comment: "No mention of what form
>of ID C asserted (i)n its IKE exchange with SG-A"
>(this refers to page 7, point 4, "C does not match PAD entries..."
>
>This is an important question.  We weren't sure we understood the question.
>We aren't sure that it matters, but we want to understand what concerns
>you might have behind the question.
>
>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
>[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.)

So, I was wondering if the kind of ID asserted by C in KE was 
relevant to the example, or any example, based on the wording here. 
maybe what should happen is to refine the description of the modified 
PAD search algorithm in section 2, which is rather brief. Maybe it 
could say something  along the lines of:

	- 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


That sort of text would avoid the ambiguity that triggered my question.

Steve