Re: AD requests WG review of final revisions todraft-ietf-ipsec-nat-reqts-06.txt <= 48hrs please

[Tero Kivinen <kivinen@iki.fi>]

Stephen Kent writes:
> >       desired, an ID type of ID_FQDN can be used.  In either case,
> >       it is necessary to verify that the proposed identifier matches that
> >       enclosed in the certificate if certificates are exchanged in Phase 1.
> 
> the pki4ipsec WG, and 2401bis, are addressing what is required to 

pki4ipsec is just starting now, we do not know what they are going to
be producing. The 2401bis refers also to IKEv2, which have its own NAT
traversal and there are differences in the IDs allowed etc. This
document is now in the RFC editor final step, I do not think we should
be modifying this text based on the future work that is still work in
progress. 

> establish that the asserted ID in the IKE payload is authorized 
> relative to the authentication data provided. thus the text here 
> seems a bit too restrictive when it says "matches that enclosed in 
> the certificate ..." I'd suggest something along the lines of "In 
> either case, it is necessary to verify that the proposed identifier 
> is authenticated as a result of processing an end-entity certificate, 
> if certificates are exchanged in Phase 1."

The original text works fine for the current IKEv1 usage, and I do not
think we should be changing the current text at this step. 

> >       While use of USER_FQDN or FQDN identity types is possible within IKE,
> >       there are usage scenarios (e.g., Security Policy Database (SPD)
> >entries
> >       describing subnets) that cannot be accommodated this way.
> >
> >       Since the source address in the Phase 2 identifier
> >       is often used to form a full 5-tuple inbound SA selector, the
> >       destination address, protocol, source port and destination port can
> >       be used in the selector so as not to weaken inbound SA processing."
> 
> I don't know what this means, precisely. We are clarifying how to use 
> named SPD entries in 2401bis, so that there will be no need to talk 
> about weakening inbound SA processing.

We do not want to wait for work in progress, i.e. rfc2401bis. This
document refers to rfc2401 which does not have the clarification yet. 

> I'd suggest using the new text on SA demuxing, from the revised AH & 
> ESP specs as approved by the WG months ago. it clarifies what is 
> required re demuxing for unicast vs. multicast traffic.

Again this document refers to rfc2401, rfc2402, rfc2406, this it
cannot use later AH and ESP documents.

If this document would be in normal working group edit phase, then
those changes would propably be ok, but as we are now in the rfc
editor 48 hours notice time, I do not think we should be doing that
kind of changes. 
-- 
kivinen@safenet-inc.com