[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: IKEv2 (son-of-ike) draft

Ari,

> Ari Huttunen wrote:
>
> As to the specifics of this protocol, in my view IKEv2 should have
> these kinds of requirements:
>[...]
> 
> - IKEv2 must be well defined. For example, this draft doesn't state
>   clearly how the critical bit is to be used (for each payload),
>   notifies are unclear and should be accompanied by a state machine.
>   I.e. if a cert payload with critical bit contains a DSS-signature,
>   is it critical that you know "cert payload", support 
>   DSS-signatures, or what?

As an IKE implementor, I agree wholeheartedly.  What I would like
to see is a section that goes through each message, and explains
how it is constructed and processed in the basic case, using pseudocode.
Sometimes the easiest way to specify the outcome is to specify the
process...  This would be the case with IKE packet processing, in
my opinion.

> - I have a strong dislike for the current VID method. It fails to
>   provide several key requirements:
>[...]

Agree to some extent, although you can already hide the new payloads
you need into VID payloads.  There is nothing (but aesthetics) to
prevent one from using, say, 16 first bytes of the VID as a vendor
identifier, and the rest as vendor-specific data.

> Here's an alternative to VIDs that we could consider:
> - A new payload is defined that defines exactly what private 
> use numbers
>   an implementation uses and what they are used for. In this 
> way the private
>   use numbers are viewed as variables, i.e.
>   #define PAYLOAD_TYPE_128  
> "draft-my-draft-whatever-00.txt:nonce-thingie"
>   etc., or use an OID instead

This sounds like a lot of complexity to me.  IKE payloads would
not be understandable without the context of the particular IKE
session (if I understood correctly) ?

Another alternative is to use an explicit vendor extension
payload (like Mobile IP) does.  The payload would have:
    (1) a vendor identifier;  could be the same number space
        as in Mobile IP, or a vendor hash (which would lead to
	  some unfortunate bloat).
    (2) extension type, length, and the usual stuff.

Thus each vendor could have their own extension playground
(and messages with vendor extensions can be included in initial
messages).

> - IKEv2 would be easier to test if a method to authenticate 
> using preshared
>   secrets was provided. Like, how about hmac-sha-1 signatures?

Preshared keys are nice for some things but they do add complexity..
Is there a way we could automatically create RSA keys for this
purpose?

Suppose you take a preshared key, and use that as an input to an
RSA keypair derivation procedure that comes up with an RSA keypair.
Both parties use the same procedure to arrive at the same RSA keypair,
used as input to the IKEv2 authentication.  This scheme can be
extended to take the IP addresses into account in the derivation
process.  The keypair would have to be generated once (expensive),
and then cached for further use to avoid overhead.

I'm sure there is some good reason why this cannot be done;
can someone point out what the reason is? :)

-Sami

---
Sami Vaarala
Senior System Architect
NetSeal Technologies