Document: draft-ietf-pana-framework-09.txt Reviewer: David L. Black Review Date: June 15, 2007 IETF Telechat Date: June 21, 2007 Summary: This draft is ready for publication as an Informational RFC Comments: The items identified in the Gen-ART review of the -08 version of this draft have been addressed in the -09 version. ========================================================================= Document: draft-ietf-pana-framework-08.txt Reviewer: David L. Black Review Date: June 4, 2007 IETF LC End Date: June 7, 2007 Note: Original LC review of -06 is found at the end of the -08 review. Summary: This draft is on the right track but has open issues, described in the review. Comments: This draft has changed significantly since it's -06 version that I previously reviewed for Gen-ART. Sections 5-10 of the -06 draft have been removed, resulting in a considerably higher level -08 document that is appropriate to publish as Informational (my previous review of -06 had expressed a concern about whether it should be standards track instead of informational). Much of my previous Gen-ART review concerned portions of the -06 draft that have been removed: http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-pana-framework-06-b lack.txt The following points from that review of -06 has not been addressed: 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 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. The latter concern needs to be noted in the Security Considerations section, even if it is addressed elsewhere - the solution need not be in this draft, but the identity correspondence problem is an aspect of the PANA framework and needs to be noted as a security consideration. - Alper's email address needs to be updated, as the one in the draft does not work. - idnits 2.04.08 complains that there's no Intended Status on the first page. ======================================================================== Draft: draft-ietf-pana-framework-06.txt Reviewer: Black_David@emc.com Review Date: Friday 3/31/2006 6:30 PM CST IETF LC Date: 4/1/2006 Summary: 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. 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. 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. 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. 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. 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. 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. 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. End of Section 9: What are "these EAP encapsulating methods"?