Subject: [Pana] Re: GenART review of draft-ietf-pana-framework-06.txt

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 11 May 2006 20:08:23 -0400

Hi David,

On Wed, May 03, 2006 at 08:31:36PM -0400, [email-masked] wrote:
> Ohba-san,
> 
> Thank you for your response.  I have a few comments:
> 
> 1) The Informational vs. Standards-track RFC issue is for the ADs
> to decide.

OK.

> 
> 2) My comment on IKE is not the same as Bernard Aboba's.  My request
> is that the references to IKEv1 [RFC 2409] be replaced with references
> to IKEv2 [RFC 4306], or at least that IKEv2 be referenced anywhere
> IKEv1 is.  If this isn't done now, the Security ADs are likely to
> ask for it during IESG evaluation.  With regard to Bernard's comment,
> I understand that PANA needs to run EAP in a situation where it may
> not be possible to use IPsec, and hence I agree with your response
> to Bernard - namely that EAP encapsulated in IKEv2 is not sufficient
> to meet PANA's requirements.

I understand.  I agree on replacing all IKEv1 references with IKEv2
references.

> 
> 3) For two level authentication, I understand your comment:
> 
> > The use of ID_KEY_ID as IKE identifier is being specified in a
> > separate standard track document (draft-ietf-pana-ipsec), with
> > specifying the rule on how to generate the ID_KEY_ID from PANA session
> > attributes.  This way PANA/EAP authentication is bound to IKE
> > identifier to prevent the man-in-the-middle attack you mentioned
> > above.
> 
> That additional information would be good to add to the draft along
> with a statement that (draft-ietf-pana-ipsec) requires the EP to check
> that the Key ID is being used with the correct PaC by virtue of the EP
> learning the IP address that corresponds to the PANA session from the
> PAA and enforcing use of that IP address with the corresponding key
> via an appropriate IPsec SPD entry.  Section 7.3 may be a more
> appropriate place for these text additions than Section 4.

OK.  I agree on having additional information on this.

Thank you,
Yoshihiro Ohba

> 
> 4.  It looks like I may have misread item 3 in Section 5 - on checking
> it now, the existing text is fine.
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> [email-masked]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> 
> > -----Original Message-----
> > From: Yoshihiro Ohba [mailto:[email-masked]] 
> > Sent: Wednesday, May 03, 2006 4:35 PM
> > To: Black, David
> > Cc: [email-masked]; [email-masked]; [email-masked]; 
> > [email-masked]; [email-masked]
> > Subject: Re: GenART review of draft-ietf-pana-framework-06.txt
> > 
> > Hello David Black,
> > 
> > Thank you for reviewing the pana-framework draft and sorry for delayed
> > response.  Please see my comments in line.
> > 
> > On Fri, Mar 31, 2006 at 07:29:42PM -0500, [email-masked] wrote:
> > > Background for those who may be unaware of GenART:
> > > 
> > > GenART is the Area Review Team for the General Area of the IETF.
> > > We advise the General Area Director (i.e. the IETF/IESG chair) by
> > > providing more in depth reviews than he could do himself of documents
> > > that come up for final decision in IESG telechat.  I was selected
> > > as the GenART member to review this document.  Below is my review,
> > > which was written specifically with an eye to the GenART process, but
> > > since I believe that it will be useful to have these comments more
> > > widely distributed, others outside the GenART group are included.
> > > 
> > > This review was done as part of IETF Last Call.
> > > 
> > > Review criteria: "Is this document a reasonable contribution to the
> > > area of Internet engineering which it covers?  If not, what changes
> > > would make it so?"
> > > 
> > > This draft is on the right track but has open issues, described
> > > in the review.
> > > 
> > > The draft is generally well-written, although I was unable to follow
> > > all of the details of the Wireless LAN examples, as familiarity with
> > > the 802.11 protocol suite is assumed.  I found a number of issues,
> > > mostly in the area of security:
> > > 
> > > This is an informational document using RFC 2119 terminology.  It
> > > needs to say something about why this is the case (e.g., who should
> > > pay attention to these requirements).  There are enough statements
> > > about things that MUST be done in certain ways that I wonder 
> > > whether this ought to be a standards track document.
> > 
> > The PANA framework document specifies components that are part of a
> > complete secure network access solution, but are outside of the PANA
> > protocol specification.  People who consider deployment of PANA and
> > implements the PANA protocol need to pay attention to the requirements
> > described in in the PANA framework document.  
> > 
> > Regarding whether this document should be a standard track document or
> > an informational document, I personally think that this should be a
> > standard track document for the same reason you mentioned above, but
> > I'd like to hear opinion from WG chairs and ADs.
> > 
> > > 
> > > Replace all citations of IKE [RFC 2409] with IKEv2 [RFC 4306],
> > > as IKEv2 is explicitly cited in some places, is the preferred
> > > protocol, and IKEv2's ability to tunnel EAP as an authentication
> > > method may be useful.
> > 
> > There is a similar comment from Bernard Aboba:
> > 
> > http://www1.ietf.org/mail-archive/web/pana/current/msg02234.html
> > 
> > Let me quote the comment and the response to it:
> > 
> > "
> > >"If the client for
> > >PANA configures an IPsec tunnel for enabling per-packet security,
> > >configuring IP addresses inside the tunnel becomes relevant, for
> > >which there are additional choices such as IKE [RFC2409]."
> > >
> > >Since IKEv2 already handles tunnel setup as well as EAP authentication,
> > >I was somewhat confused by this.  Why would PANA be needed in such a 
> > >scenario? 
> > 
> > IKEv2 does not satisfy the requirements that were set in RFC 4058, most
> > importantly 4.5.1. For that, and for the various other features of PANA, I
> > don't think IKEv2+IPsec can substitute PANA+IKEv1/IKEv2+IPsec. That's not
> to
> > say there wouldn't be any deployments using the former suite.
> > "
> > 
> > > 
> > > Section 3 could use a discussion about the relationship of the access
> > > network to the network that PANA controls access to.  Figure 1 ought
> > > to show the latter (accessed) network as connected to the EP, and a
> > > two-cloud ASCII diagram would be very useful.  Among other things,
> > > this would make it clear that the access network is in general a
> > > shared access network (as opposed to consisting entirely of
> > > per-client private links, as is the case for DSL), helping set up
> > > the first paragraph in Section 6.
> > 
> > OK, we will add two clouds in Figure 1, one for accessed network and
> > the other for access network, both connected to EP.
> > 
> > > 
> > > Section 4 talks about authentication at two levels - the lower level
> > > (link native or IPsec) and EAP over PANA.  It needs to describe the
> > > recommended or required relationships between the identities used
> > > for these authentications.  If there is no relationship, there is
> > > a potential vulnerability (particularly in the IPsec scenario) to
> > > a man-in-the-middle attack where the secure channel ends are not
> > > at the PaC and EP.  It appears that in the IPsec case, the preferred
> > > identity is ID_KEY_ID (i.e., here's a key, trust anyone who presents
> > > it), which is not the most robust approach.
> > 
> > The use of ID_KEY_ID as IKE identifier is being specified in a
> > separate standard track document (draft-ietf-pana-ipsec), with
> > specifying the rule on how to generate the ID_KEY_ID from PANA session
> > attributes.  This way PANA/EAP authentication is bound to IKE
> > identifier to prevent the man-in-the-middle attack you mentioned
> > above.
> > 
> > > 
> > > Section 5 item 3 (address configuration method) assumes stateless
> > > address autoconfiguration for IPv6.  That's not a correct
> > > assumption for all IPv6 nodes (see RFC 2461 and its discussion of
> > > DHCPv6), so either:
> > > - State an affirmative requirement for stateless address auto-
> > > 	configuration (e.g., a PaC supporting IPv6 MUST use stateless
> > > 	address autoconfiguration). OR
> > > - Rewrite this item to include a discussion of DHCPv6.
> > 
> > In Section 5 item 3 we assume stateless address autoconfiguration for
> > configuring a link-local address.  For non-link-local address, we
> > don't always assume stateless address autoconfiguration for IPv6.  In
> > fact, the possible use of DHCP is mentioned in the text:
> > 
> > "
> >    3. In IPv6, clients automatically configure a link-local address
> >       [RFC2462] when they initialize an interface.  Additionally, they
> >       may also configure global address(es) when DHCP or router
> >       advertisements with global prefixes are made available to the
> >       them.
> > "
> > 
> > Perhaps we should say DHCPv6 instead of DHCP in the above text.
> > 
> > > 
> > > The network layer protection paragraph (3rd paragraph) in section 6
> > > is a bit unclear.  It should be edited to make the following two
> > > points clear:
> > > (1) The shared secret obtained from an EAP method is insufficient
> > > 	to use as a manual key for an IPsec SA in general, as multiple
> > > 	keys are often required, and manual keys cannot be automatically
> > > 	rekeyed in general.  The recommended way of dealing with this
> > > 	is to use the shared secret as a shared secret for IKEv2
> > > 	authentication to generate the required keys and support
> > > 	rekeying.
> > > (2) IPsec requires significant configuration (e.g., crypto algorithms,
> > > 	traffic selectors).  IKEv2 takes care of this also.
> > > Point (2) is reasonably well made in the text, but earlier than it
> > > should be.  Point (1) is not as obvious.
> > 
> > 
> > Yes, these are clearer.  We will revise the paragraph based on your
> > suggestion.
> > 
> > > 
> > > The last paragraph of section 6 discusses ciphers and ciphering.
> > > In general, requirements for confidentiality are accompanied
> > > by requirements for (cryptographic) integrity.  The paragraph
> > > should be rewritten in light of this to make it clear that
> > > cryptographic integrity will be required in general.  Weaknesses
> > > in link layer security (e.g., WEP) can be a motivation to use
> > > IPsec in addition to whatever the link layer provides.
> > 
> > I agree.  We will revise the paragraph accordingly.
> > 
> > > 
> > > Section 7.3 is recommending ID_KEY_ID as the IKE identity.
> > > This is not the best choice if there are other identities available
> > > (e.g., if the key is bound to a specific IP address, that IP
> > > address is a better identity).  Even repeating the PANA EAP method
> > > through IKEv2 may be preferable to ID_KEY_ID.
> > 
> > Please see my earlier comment on ID_KEY_ID.  We are taking a strict 
> > approach to mandate ID_KEY_ID.
> > 
> > > 
> > > End of Section 9: What are "these EAP encapsulating methods"?
> > 
> > It should read "these EAP methods".
> > 
> > Best regards,
> > Yoshihiro Ohba
> > 
> > > 
> > > Thanks,
> > > --David
> > > ----------------------------------------------------
> > > David L. Black, Senior Technologist
> > > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > > [email-masked]        Mobile: +1 (978) 394-7754
> > > ----------------------------------------------------
> > > 
> > 
> 

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Mark Townsley <[email-masked]>
Date: Fri, 12 May 2006 08:25:00 +0200

>> 1) The Informational vs. Standards-track RFC issue is for the ADs
David is right, we typically publish Framework documents Informational.

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Fri, 12 May 2006 08:38:20 +0200

>> 1) The Informational vs. Standards-track RFC issue is for the ADs
Please disregard the last statement - I misread the email exchange.

> I'd like to hear opinion from WG chairs and ADs.

I still agree with David, and can see the argument for this being
standards track based on this logic. I'd like input from other IESG
members though.

- Mark

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 12 May 2006 10:23:34 +0300

> I understand.  I agree on replacing all IKEv1 references with IKEv2

Does that mean the specs will only support IKEv2, and IKEv1 is not
supported? Do we really want to have such a limitation?

Alper