Subject: [Gen-art] GenART review of draft-ietf-pana-framework-06.txt

From: [email-masked]
Date: Fri, 31 Mar 2006 19:29:42 -0500

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.

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"?

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
----------------------------------------------------

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art