[anonsec] comments on the BTNS core I-D

[Stephen Kent]

At 2:19 PM -0500 7/26/07, Michael Richardson wrote:
>S...
>  > 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).

I didn't say that the key isn't transmitted; I just noted the wording 
in the document that says that the new IKE ID type is not carried on 
the wire.

The new text on page 4 also says "Nodes wishing to be treated as BTNS 
nodes by their peers MUST include bare RSA key CERT payloads.  Nodes 
MAY also include any number of certificates that bind the same public 
key.  These certificates need not to have been pre-shared with their 
peers (e.g., because ephermal, self-signed)."

first, "ephemeral" is misspelled and there seems to be a word missing 
in that parenthetical phrase.

Second, the text refers to bare RSA key payloads, plural, but I 
assume is it acceptable to send just one such payload, right? in 
fact, would it make sense to send more than one? also, the text 
allows additional cert payloads, but only of they contain the same 
key as the bare RSA payload, but the wording is confusing.  I suggest 
the following rewording, if my assumptions about your intent are 
correct:

A node that wishes to be treated as BTNS node by a peer MUST include 
at least one Raw RSA Key CERT payload.  A node also MAY include one 
or more certificate payloads of types other than Raw RSA Key, but 
only if they contain the same public key as the Raw RSA Key CERT 
payload.  These additional certificates need not have been pre-shared 
with the peer in (e.g., because they may be ephemeral, or 
self-signed).

A final question re this text: why allow sending additional certs?

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

I think you and Nico should agree on this point, and clarify the text 
if needed.
Nico's message refers to the potential for additional PAD entries 
that match PUBLICKEY, but if this ID type was created only to support 
BTNS entries, then his message is saying that there can be multiple 
such entries. Right now the text seems to indicate just one BTNS PAD 
entry, and requires it to be in the last slot.

Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/anonsec/attachments/20070727/8476e0c6/attachment.html