On 06/30/2014 10:46 AM, Tom Taylor wrote:
Comments below marked with [PTT].
Tom Taylor
On 28/06/2014 1:53 PM, Tom Henderson wrote:
Hi all, we received a number of comments during the IESG evaluation of
RFC 5201-bis. Below are the non-editorial comments. There were also
several IANA questions that I plan to handle in a separate message.
I'll plan to post an updated draft version 15 that addresses the
editorial comments received, then once we give people a chance to review
the below, publish another new version with additional revisions.
Please review the below suggested resolutions (there is one issue for
which I am not sure whether we should make any changes).
Minor issues (pointed out by Gen-ART reviewer Tom Taylor)
---------------------------------------------------------
1) Section 4.3 (Error Processing) final case: if the receiving host does
not send some sort of response (e.g., ICMP) to the sender, the sender
may have no way of knowing that the HIP session has failed. The state
transitions from ESTABLISHED in Table 6 time out on no packet
"sent/received" for a given period of time. If the sending application
doesn't expect a response, it could be sending packets that are ignored
at the other end for an indefinitely long time. At the least, this point
should be brought out in the text of that error case, and possibly the
ICMP response should be RECOMMENDED.
Discussion: Sending ICMP packets in response to this situation could
also possibly be abused for DoS, so sending of ICMP should be
rate-limited in this case. I'm proposing some text to try to balance
these concerns; any comments or other suggestions?
OLD TEXT:
Optionally, the receiving host MAY send an ICMP packet, with
the type Parameter Problem, to inform the sender that the HIP
association does not exist (see Section 5.4), and it MAY
initiate a new HIP BEX. However, responding with these
optional mechanisms is implementation or policy dependent.
SUGGESTED NEW TEXT:
Optionally, the receiving host MAY send an ICMP packet, with
the type Parameter Problem, to inform the sender that the HIP
association does not exist (see Section 5.4), and it MAY
initiate a new HIP BEX. However, responding with these
optional mechanisms is implementation or policy dependent.
If the sending application doesn't expect a response, the
system could possibly send a large number of packets in this
state, so for this reason, the sending of one or more ICMP
packets is recommended. However, any such responses should
be rate-limited to prevent abuse (see Section 5.4).
[PTT]
s/recommended/RECOMMENDED/ in the second-last line
Why "should" at the end of that line rather than MUST?
OK, if I change to capitalized RECOMMENDED, should the first sentence
also be changed from MAY to RECOMMENDED (i.e. are MAY and RECOMMENDED
incompatible terms)?
I would be fine with changing the last line to a MUST.
2) Section 5.2.7: when the host supports more than one D-H Group, is
each group specified in a separate instance of the Diffie-Hellman
parameter? The text does not say.
Discussion: This seems to require some clarification. The
DH_GROUP_LIST in I1 is used to select the single instance of
DIFFIE_HELLMAN sent in the R1. I also found some awkward wording
in the parameter definition of 5.2.6.
OLD TEXT in section 5.2.6:
DH GROUP ID defines a DH GROUP ID supported by the host.
The list of IDs is ordered by preference of the
host. The list of define DH Group IDs in the
DIFFIE_HELLMAN parameter. Each DH Group ID is one
octet long.
NEW TEXT in section 5.2.6:
DH GROUP ID defines a DH GROUP ID supported by the host.
The list of IDs is ordered by preference of the
host. The possible DH Group ID values are defined
in the
DIFFIE_HELLMAN parameter. Each DH Group ID is one
octet long.
[PTT] The parameter contents do not constitute a definition. (But the
description of the parameter in the document does -- hope this isn't too
confusing.) I think s/defines/specifies/ was one of my suggested
editorial changes.
I am fine with the change to 'specify'.
OLD TEXT in section 5.2.7:
The following Group IDs have been defined:
NEW TEXT in section 5.2.7:
A single DIFFIE_HELLMAN parameter may be included in selected
HIP packets based on the DH Group ID selected (section 5.2.6).
The following Group IDs have been defined:
[PTT] Good.
3) Section 5.2.18: given the strict ordering of HIP parameters, the
initial
plaintext for the Encrypted content (type and length of initial
parameter) may be fairly easily guessed. This opens up the minor
possibility of a known plaintext attack. [Comment to be reviewed after
further examination.] [Upon review: I1 packets have fixed type but
variable length due to varying lengths of DH-GROUP-LISTS. The set of
such lengths is limited, however, so it is worth considering whether
known plain-text attacks offer any real threat.]
Discussion: I don't know how/whether to handle this, or whether other
similar vulnerabilities in other security protocols are addressed.
Changes to address this would likely complicate things or increase the
packet sizes.
[PTT] I have to leave it to people more knowledgeable in security to
judge whether this is a realistic attack. One point of approach is to
find out what sample size is needed for known plain-text attacks for
specific algorithms, compare that with the rate at which an attacker
could collect encrypted messages in specific scenarios, and decide
whether there is a real threat. Mitigation presumably might be through
adjustment of the rate of key rollover.
Unsure; leaving to others to comment.
Thanks,
Tom
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
