[Gen-art] Gen-ART HIP drafts (base and esp) review

[[e-mail]]

I have been selected as the General Area Review Team (Gen-ART) 
reviewer for this draft (for background on Gen-ART, please see 
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments 
you may receive.

Document: <draft-ietf-hip-base-06.txt> and <draft-ietf-hip-esp-04.txt> 
Reviewer: David L. Black
Review Date: November 19, 2006
IETF LC End Date: November 19, 2006

These drafts are on the right track, but have open issues, described
in the review.

The drafts are in very good shape - the key security areas are well-
specified, and in some cases better than some of what I've seen in
IPsec drafts.  The open issues are those not marked as nits below -
the only one that looks potentially serious/difficult is the dependence
on IP fragmentation.

<draft-ietf-hip-base-06.txt>

Nit: The phrase "standard authenticated Diffie-Hellman key exchange for
session key generation" occurs starting in Section 4.1 - explain
what "standard" means.

The treatment of Opportunistic Mode in Section 4.1.6 is "interesting"
for a security protocol document in that it deliberately omits the
details and security considerations.  If this draft were headed for
Proposed Standard RFC status, that would be grounds for removal of
Opportunistic mode, but this draft is headed for Experimental RFC
status, for which the lack of details may be acceptable.  If the
Security Area has not already  commented on this (e.g., in the secdir
review), please bring this issue to their attention.

Section 5.1.3 indicates a reliance of HIP on IP fragmentation.  IP
fragmentation is becoming increasingly troublesome, so this will
be a problem in practice.  The corresponding reliance on IP
fragmentation for IKE is a known cause of problems with certificates,
as the size of some certificates is a common cause of IP fragmentation
with UDP/IP.  At a minimum, this section should carry a strong
recommendation that the separately-specified HIP support for
certificates support Hash & URL certificate formats in order to
avoid certificate sizes that will cause IP fragmentation.  Certificates
are a major cause of IP fragmentation in IKE, particularly when chains
are involved.

The text in Section 5.3.2 on Diffie-Hellman value reuse could use
some clarification.  The underlying issue is that the HIP exchange
does not use  the nonces that IKE and IKEv2 use, which makes DH
value reuse significantly more dangerous.  The current text says
that DH values SHOULD not be reused unless the system is under attack
(I1 storms), in which case they MAY be reused.  This appears to drop
the level of security in response to an attack, which may not be the
best course of action.  I don't want to say that HIP ought to use
IKE-like nonces, but this text appears to need some more thought.

Section 5.3.3 doesn't discuss DH value reuse.  It should.

Section 5.3.6 and Section 6.13 need more precision on the sorts of
"state information changes" that SHOULD NOT be made as a consequence
of receiving a NOTIFY packet.

Section 6.5 needs to specify how to calculate the Diffie-Hellman
Kij value.

Nit: In Section 6.6.1, the connection between limitations on sending
I1's
and DoS attacks is not clear.  A DoS attacker will not respect the
limitations in this section, so the discussion might be in terms of
not making a bad situation worse (probably already covered under
"network congestion") or detection of a DoS attack at the receiver
by determining that the sender is not observing these limitations.

Nit: In Section 9, please give IANA some guidance on how to deal with
the unused Notify Message Type values that are less than 42.

<draft-ietf-hip-esp-04.txt>

Nit: Section 3.3.5, change "AES" to "AES-CBC" in two places.
There are AES modes other than CBC defined for use with ESP.


Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------

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