[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IKEv2 (son-of-ike) draft
On 17 Nov 01, at 23:10, dharkins@tibernian.com wrote:
> This draft was submitted but hasn't shown up yet in the repository
> (the I-D editor is, no doubt, swamped) so in the interest of giving
> people more time to look at it prior to Salt Lake here's a link:
>
> http://www.lounge.org/draft-ietf-ipsec-ikev2-00.txt
>
> Please send comments to the list.
>
> Dan.
I've read through the draft and have some comments and questions.
1. It seems that peers have no ability to learn what type of
signature (RSA, DSS or smth else) the other party uses apart from
investigating the type of public key contained in certificate.
Because of certificate exchange is optional, it makes the protocol
unworkable in some situations. Consider the example, when party A
supports only RSA signatures, and party B supports both RSA and DSS
signatures with DSS as preferable. While party B will be able to
verify signature, generated by party A, the other party won't be able
to do it, if party B will use its favourite (DSS). Moreover, party A
has no ability to inform party B that she doesn't support DSS. Even
the exchange of certificates doesn't help much - party B may have
both RSA and DSS certificates from the same CA and she still will
select her favourite - DSS, because she has no ability to learn that
her peer doesn't support DSS at all.
I can think of two ways to improve the situation.
a) use notification INVALID-SIGNATURE to inform the other party that
this type of signature algorithm is not supported. The problem with
this solution is that with the lack of explicit knowledge of peer's
public key type (if no cert exchange took place) the peer could not
be able to always distinguish unsupported signature algorithm and
just bad signature.
b) add attribute "Signature algorithm" to transform "Authentication
method", making the algorithm negotiateable. This will, however,
eliminates the ability for each of the peers to use different
algorithm.
As for me, I like option b).
2. The draft says that responder may return a subset of TS proposed
by initiator. While I like the idea in general, there is a problem:
responder doesn't know what packet triggered IKE at initiator, so it
can falsely narrow down TS so, that original packet at initiator
won't fit into resulting SA, forcing initiator to perform one more
Phase 2 (possibly with the same result). For responder to be more
smart in this narrowing, some information about the packet, triggered
the negotiation must be provided by initiator.
Again, I can see 2 ways how this information may be provided.
a) define a new payload type - say "Original packet" payload, very
similar in format to Traffic Selector Substructure or to current ID
payload (not to IKEv2 ID payload). Such payload must be sent by
initiator along with TS payloads. They must be filled with
information from the very packet, that triggered this negotiation.
For responder this payloads will be an indication of IP addresses,
protocol and ports that must be always be met while she will be
narrowing initiator's TS.
b) it is possible to avoid defining new payload type if initiator
will always fill the very first TS Substructure with the information
from the packet, triggered negotiation. She may provide additional TS
Substructures as a proposal for SA selector, and responder will be
knowing that she may narrow this proposal to any extent except that
the requirements of the the very first TS Substructure must always be
met after the narrowing.
I have no strong opinion what solution is better.
Few minor comments and questions.
3. It seems that TS payloads are required in IKEv2, eliminating the
simplest case in IKEv1, when it was allowed to omit ID in Quick Mode.
Is it right?
4. Reference to RFC 2522 (on page 10) is absent in References
section.
5. Section 2.2, second paragraph. "... with is zero" - did you mean
"... which is zero"?
6. Section 7.3.2, table Transform Type Values, "Integrity Algorithm"
line. Is it a typo that IKE is mentioned in this line or is it for
purpose? I cannot figure out how it is applicable to IKE and if it
is, how does it interact with PseudoRandom Function values.
7. Page 30,31 - there seems to be too many bullets in description of
Proposal Substructure and too few in description Transform :-)
Regards,
Valery Smyslov.
References: