[anonsec] comments on the BTNS core I-D

[Nicolas.Williams at sun.com (Nicolas Williams)]

On Fri, Jul 27, 2007 at 05:15:22PM -0400, Stephen Kent wrote:
> 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.

Correct.  A new IKE ID would be primarily useful as an implementation
detail, but probably useful enough to be worthy of having an assignment
for it.

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

It was misspelled, and no word is missing ("because <adjective>" is a
legitimate English language idiom, as in "Joe was lazy because
spoiled").  It is an odd idiom, but one that I'm fond of.

> Second, the text refers to bare RSA key payloads, plural, but I 
> assume is it acceptable to send just one such payload, right? in 

It is plural because the nodes will be doing multiple IKE exchanges with
many peers thus there will be multiple bare RSA key payloads.

But in one IKE exchange there should be a single payload because there
can be only one AUTH payload so there can really only be one public key.

> fact, would it make sense to send more than one? also, the text 

Having multiple CERT payloads per-exchange all using the same public
key, as in different certs for the same key, seems OK, and even useful.

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

I like it, thanks.

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

Because it would allow a node to do better than BTNS with some peer if
that peer could authenticate it; the node need not know a priori that
its peer can do so.  RFC4306 doesn't seem to disallow multiple CERT
payloads, but the structure of the protocol is such that only one AUTH
payload makes sense, thus all CERT payloads should use the same public
key.

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

The BTNS catch-all entry must be the last one in the PAD.  There may be
PAD entries that match specific public keys -- these must come before
the BTNS catch-all PAD entry.