[anonsec] comments on the BTNS core I-D
Nico
Nicolas.Williams at sun.com
Thu Jul 26 12:37:31 PDT 2007
On Thu, Jul 26, 2007 at 02:19:28PM -0500, Michael Richardson wrote:
> 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
> >
> > - the PAD is searched again, using this new ID type and value
Indeed, if there are any PAD entries matching a specific public key,
then those must take precedence over the catch-all BTNS PAD entry.
> > - 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?
No. PAD entries that match specific PUBLICKEY IDs must come before the
catch-all BTNS PAD entry (which MUST be last); they must also come
logically after any PAD entries matching other ID types.
> The two searches can be implemented with a single scan, with a priority based
> comparison (i.e. keep on the best match).
Indeed. We need only describe a canonical approach though, but we could
certainly say that a one-pass optimization is feasible.
Nico
--
More information about the ANONSEC
mailing list