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

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 03 May 2006 16:35:00 -0400

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: "Tschofenig, Hannes" <[email-masked]>
Date: Wed, 17 May 2006 12:28:20 +0200

Hi Mark, 

as a counterargument:

IKEv2 does not mandate the implementation of RADIUS (Diameter,etc.) for the interface between the IKEv2 responder and the backend infrastructure. 

For the EP - PAA interface I personally would go for API (i.e., PAA and EP co-located) as the minimum requirement. 

Ciao
Hannes

> -----Ursprüngliche Nachricht-----
> Von: Mark Townsley [mailto:[email-masked]] 
> Gesendet: Mittwoch, 17. Mai 2006 09:52
> An: Alper Yegin
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; 'Jari Arkko'; [email-masked]; [email-masked]
> Betreff: Re: [Gen-art] RE: [Pana] Re: GenART review of 
> draft-ietf-pana-framework-06.txt
> 
> Alper Yegin wrote:
> >>> I believe the Security Area allows whatever makes sense.  
> I would have no
> >>> problem with "IKEv2 [] referenced anywhere IKEv1 is" as 
> was stated in the
> >>> original review, and it would probably be possible to get 
> the current
> >>> IKEv1-only situation through the security area ADs if 
> IKEv2 raised new
> >>> issues around integration w/PANA that are not covered in 
> the current
> >>> PANA draft, but that would need to be explicitly stated 
> in the draft.
> >>>
> >>>
> >>>       
> >> >From a theoretical perspective it would be interesting to know
> >> whether there's any difference between using IKEv1 and IKEv2
> >> for this purpose. But from an interoperability perspective it
> >> would be very useful for implementors to know if they need
> >> to support one or the other. PANA clients need to work
> >> with PANA network infrastructure, and mandating both versions
> >> would propably be an overkill.
> >>
> >> I agree with David that IKEv2 should be the default assumption
> >> in new specs unless we have a very good reason to say otherwise.
> >>     
> >
> > Jari,
> >
> > Can you expand on this a bit more, so that we know what to 
> do in the PANA
> > framework document. Given that both IKEv1 and IKEv2 can be 
> used to create
> > the associated IPsec SAs after PANA authentication, and
> > draft-ietf-pana-ipsec-07.txt provides details (and differences when
> > present), what would be the appropriate language to capture 
> what you are
> > saying above?
> >   
> If you do allow both, then when someone advertises "I can do 
> PANA" they 
> have to qualify it with "IKEv1 or IKEv2?"
> 
> I think PANA is already challenged with multiple possible interfaces 
> between the EP and PAA and the PAA and AS, now you will have the same 
> between the PAC and EP. If each interface has multiple 
> options, "PANA" 
> won't mean much without a lot of qualifiers.
> 
> I still recommend at least one "MUST IMPLEMENT" for each 
> interface, so 
> that PANA will at work "out of the box" in at least one 
> configuration no 
> matter who your EP, PAA, AS, PAC, vendor is. Alternative 
> protocols (or 
> versions of protocols) can still be options if someone wants 
> to improve 
> on the base configuration or needs to provide backwards compatibility 
> with some non-fully-compliant device.
> 
> - Mark
> >
> >
> >
> >   
> >> --Jari
> >>     
> >
> >   
>