Re: IKEv2 (son-of-ike) draft

["Valery Smyslov" <[e-mail]>]

On 17 Nov 01, at 23:10, [e-mail] 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.