[anonsec] comments on the BTNS core I-D
kent at bbn.com (Stephen Kent) Fri, 27 July 2007 21:15 UTC
From: "kent at bbn.com"
Date: Fri, 27 Jul 2007 17:15:22 -0400
Subject: [anonsec] comments on the BTNS core I-D
In-Reply-To: <f8as41$dt0$1@sea.gmane.org>
References: <p06240505c2cd5414684e@[172.28.170.76]> <f89aup$pa$1@sea.gmane.org> <p06240508c2ce6ce745e0@[130.129.16.169]> <f8as41$dt0$1@sea.gmane.org>
Message-ID: <p06240507c2cfef99ae12@[128.89.89.71]>
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
- [anonsec] comments on the BTNS core I-D Stephen Kent
- [anonsec] comments on the BTNS core I-D Sam Hartman
- [anonsec] comments on the BTNS core I-D Michael Richardson
- [anonsec] comments on the BTNS core I-D Stephen Kent
- [anonsec] comments on the BTNS core I-D Michael Richardson
- [anonsec] comments on the BTNS core I-D Michael Richardson
- [anonsec] comments on the BTNS core I-D Nico
- [anonsec] comments on the BTNS core I-D Stephen Kent
- [anonsec] comments on the BTNS core I-D Nicolas Williams
- [anonsec] comments on the BTNS core I-D Derrell Piper
- [anonsec] comments on the BTNS core I-D Stephen Kent
- [anonsec] comments on the BTNS core I-D Nicolas Williams
- [anonsec] comments on the BTNS core I-D Nicolas Williams
- [anonsec] comments on the BTNS core I-D Stephen Kent
- [anonsec] comments on the BTNS core I-D Nicolas Williams
- [anonsec] comments on the BTNS core I-D Derrell Piper
- [anonsec] comments on the BTNS core I-D Nicolas Williams