[anonsec] comments on the BTNS core I-D

kent at bbn.com (Stephen Kent) Mon, 30 July 2007 16:27 UTC

From: kent at bbn.com (Stephen Kent)
Date: Mon, 30 Jul 2007 12:27:44 -0400
Subject: [anonsec] comments on the BTNS core I-D
In-Reply-To: <20070730154751.GC1199@Sun.COM>
References: <p06240505c2cd5414684e@[]> <f89aup$pa$1@sea.gmane.org> <p06240508c2ce6ce745e0@[]> <f8as41$dt0$1@sea.gmane.org> <p06240507c2cfef99ae12@[]> <20070730154751.GC1199@Sun.COM>
Message-ID: <p06240518c2d3bdce3f9f@[]>

At 10:47 AM -0500 7/30/07, Nicolas Williams wrote:
>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.

For standards documents we tend to look for somewhat more formal writing :-).

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

This is another place where it's better to use singular instances as 
examples, rather than plural instances.  The use of a plural instance 
as a subject creates ambiguity in the rest of the sentence, because 
one cannot know whether the later plural objects apply to each 
instance of the subject, or are due to the use of a plural subject. 
That's why I suggested re-writing text from "nodes" to "a node" in 
other parts of the document.

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

That makes sense for this type of CERT payload; IKE does not provide 
guidance about specific CERT payload sub-types, just for the overall 
payload type, so it is helpful to provide that guidance here.

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

yes, and it would be appropriate to not that here.

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

I agree that a BTNS "catch-all" entry must come last, but that entry 
is described with two adjectives: BTNS and "catch-all." So, can there 
be a BTNS's entry that matches a specific PUBLICKEY ID type and thus 
is not "catch-all?" I think that was Michael's question, and mine. If 
we say that a BTNS PAD entry is any PAD entry that uses the PUBLICKEY 
ID type, then syntactically this would allow other than catch-all 
BTNS entries.