[anonsec] comments on the BTNS core I-D

[Michael Richardson]

Stephen Kent wrote:
> 	- 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

Index: ietf-btns-core.xml
===================================================================
RCS file: /l/users/nico/btns/drafts/ietf-btns-core.xml,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -5 -r1.20 -r1.21
--- ietf-btns-core.xml	26 Jul 2007 01:40:52 -0000	1.20
+++ ietf-btns-core.xml	26 Jul 2007 19:29:13 -0000	1.21
@@ -132,20 +132,35 @@
  	    <t>The IPsec processing model is hereby modified as follows:
  		<list style='symbols'>
  		    <t>A new ID type is added, 'PUBLICKEY'; IDs of this
  			type have public keys as values.  This ID type
  			is not used on the wire.</t>
+
  		    <t>A BTNS-specific PAD entry.  This entry MUST
  			be the last entry in the PAD when
  			BTNS is enabled.  A peer that matches no other
  			PAD entries is to be "authenticated" by
  			verifying that the signature in its AUTH
                          payload in the IKEv2 exchange with
  			the public key from the peer's CERT payload.
  			The peer's ID MUST then be coerced to be of
  			'PUBLICKEY' type with the peer's public key as
  			its value.</t>
+
+                    <t>To accomplish the above, search the PAD as normal,
+                       with the ID provided by the peer. If it matches do
+                       normal processing.  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 payload.</t>
+
+                    <t>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.
+                    </t>
+                    <t>If there is no match, the IKE SA is rejected</t>
+
  		    <t>A new flag for SPD entries: 'BTNS_OK'.  Traffic
  			to/from peers that match the BTNS PAD entry will
  			match only SPD entries that have the BTNS_OK
  			flag set.  The SPD may be searched by address or
  			by ID (of type PUBLICKEY, for BTNS
@@ -184,11 +199,12 @@
                  SAs.

  		In the first pass the PAD is searched for a matching PAD
  		entry as usual, and in the second it is searched to make
  		sure that BTNS peers' asserted child SA traffic
-		selectors do not conflict with non-BTNS PAD entries.</t>
+		selectors do not conflict with non-BTNS PAD entries.
+             </t>
  	</section>

          <section title="Usage Scenarios">
  	    <t>In order to explain the above rules a number of scenarios
  		will be examined.  The goal here is to persuade the reader
@@ -498,10 +514,14 @@
  		to create new registrations nor new registries.  (The
  		new ID type is not used on the wire, therefore it need
  		not be assigned a number from the IANA IKEv2
  		Identification Payload ID Types registry.)</t>
          </section>
+
+        <section title="Acknowledgements">
+            <t>Thanks for the following reviewers: Stephen Kent</t>
+        </section>
      </middle>

      <back>
  	<references title="Normative References">
  	    &rfc2119; &rfc4301;