Hi all.
Wer'e down to single digits with the open issues on IKEv2bis. Here are 5 more.
Issue #168 - Identifier field in the EAP payload
================================================
3.16: the text here, "...this field MAY be set to any value" implies that the
Identifier field can be constant, e.g. always zero. But this would contradict
RFC 3748, that says:
In order to avoid confusion between new Requests and retransmissions, the
Identifier value chosen for each new Request need only be different from the
previous Request, but need not be unique within the conversation. One way to
achieve this is to start the Identifier at an initial value and increment it
for each new Request. Initializing the first Identifier with a random number
rather than starting from zero is recommended, since it makes sequence attacks
somewhat more difficult.
No discussion so far. I would just remove that sentence, because EAP is
specified in its own RFC, and we don't need to really specify what goes in any
of the fields. I would stay with the following:
o Identifier (1 octet) is used in PPP to distinguish replayed
messages from repeated ones. Since in IKE, EAP runs over a
reliable protocol, it serves no function here. In a response
message, this octet MUST be set to match the identifier in the
corresponding request.
Anyone think differently?
Issue #169 - Clarify what is "overrun" vulnerability
====================================================
5: what do we mean by "leaves all SAs vulnerable to ... overrun of either
endpoint"?
No discussion so far. The offending paragraph is this:
Repeated rekeying using CREATE_CHILD_SA without additional Diffie-
Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a
single key or overrun of either endpoint. Implementers should take
note of this fact and set a limit on CREATE_CHILD_SA exchanges
between exponentiations. This document does not prescribe such a
limit.
I agree that this is not very clear. Perhaps this is about overrunning the
message counter of IKE? Anyway, I would just drop the "or overrun of either
endpoint" bit.
Issue #170 - Legacy, and soon-to-be legacy, group
=================================================
"Diffie-Hellman group number two, when used with a strong random number
generator and an exponent no less than 200 bits, is common for use with 3DES.
Group five provides greater security than group two. Group one is for historic
purposes only and does not provide sufficient strength except for use with DES,
which is also for historic use only."
In view of recent advances in factoring 768-bit numbers, I suggest to revise
the text about specific group strengths in Sec. 5 - or remove it altogether. It
is non-normative, so it's probably best to eliminate it.
Similarly, in B.1 (Group 1), we may want to add: "Use of this group is NOT
RECOMMENDED." This new text may seem normative, but it is fully justified by
the text quoted above, from RFC 4306.
Since Tero and Pasi objected to changing this, and Yaron agreed to drop this, I
suggest that is the course we should take.
Issue #171 - Missing text before example in section 2.8.2
=========================================================
Section 2.8.2 there was removed paragraph:
However, there is a twist to the other case where one rekeying finishes first:
and I think some kind of paragraph is needed, as the example given below is not
about normal simultaneous IKE SA rekey, but this special case. Now someone
might think that the example given is the normal simulatenous IKE SA rekey
example.
Tero later suggested some text:
With IKEv2 rekey case there is also one another special case in addition to
normal simultaneous rekeying cases, i.e. when the one peer finishes its rekey
before it even notices that other end is doing rekey:
I think this is OK. Others?
Issue #172 - Config payload text in Section 4
=============================================
Section 4 of IKEv2bis states:
A minimal IPv4 responder implementation will ignore the contents of the CP
payload except to determine that it includes an INTERNAL_IP4_ADDRESS attribute
and will respond with the address and other related attributes regardless of
whether the initiator requested them.
A minimal IPv4 initiator will generate a CP payload containing only an
INTERNAL_IP4_ADDRESS attribute and will parse the response ignoring attributes
it does not know how to use.
The terms "minimal IPv4 responder implementation" and "minimal IPv4 initiator"
are confusing and misleading. This text is a restatement of the previous
paragraph.
This text should be removed or reworded to describe IPv6 implementation
behaviour to the same extent. It should also be reworded to clarify what is
meant by "minimal implementation." Since responding to a config payload is
optional, a "minimal implementation" in this context must refer to an
implemenation that minimally supports responding to a config payload.
The recommendation is to remove this paragraph. It adds no new information and
adds no clarify to the text in the previous paragraph.
Rather than opening the can of worms that is defining a "minimal IPv6
implementation" I think we should accept Dave's suggestion and remove both
paragraphs.
As always, silence is interpreted as consent. Please send your objections to
the list.
Yoav
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
