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

Re: IKE Loose Ends?

  Charles,

> In the recent IKE draft (...oakley-07.txt), it says in Section 4 that several
> attributes are negotiated as part of an ISAKMP security
> association; namely, encryption algorithm, hash algorithm, authentication
> method,  and group information.
> 
> In the same section, it states that if a 'prf' is not negotiated, the HMAC
> version of the negotiated hash algorithm is used as a
> pseudo-random function.
> 
> I have several questions, which I have not been able to find answers to in the
> latest round of drafts:
> 
> 1) What process is used for the "negotiation"? I was not able to find anything
> in the IPSec DOI that lets me specify either
>  a "ISAKMP hash function" or an "ISAKMP authentication method".  Can someone
> point me to the right draft where I can find
> the necessary code points and/or attributes to use?

IKE attribute negotiation is not covered by the IPSec DOI. The IPSec DOI
covers IPSec negotiation. The attributes necessary to do IKE negotiation
are in the IKE draft itself, in Appendix A. It has been like this from
the start.

> 2) At the bottom of section 4.4 it says that IKE implementations must support
> MD5 and SHA (presumably as the hash algorithms?)
> Is this really correct, given that everywhere else throughout the IPSec drafts,
> the non-HMAC versions of MD5 and SHA are never
> mandatory, and are usually deprecated?

Yes, this is correct. Native (non-HMAC'd) hashing is used in IKE for
things like IV generation and signature payload generation. Section 4
specifically says, "The negotiated hash function must be supported in
both native and HMAC modes."

> 3) In Section 5 on page 10, it says that four different authentication methods
> are allowed with Main Mode or Aggressive Mode, but
> they are not enumerated anywhere.  What are the methods?  I'm guessing that
> they are the ones described in sections 5.1 through
> 5.4.  Is this correct?

Correct.

> 4) Besides being able to specify a "method", I would have expected that one
> would also need to specify an "algorithm" to be used
> by the "method".  For example, if "digital signature" is the chosen
> authentication method, how does one specify which digital signature
> algorithm is actually being used (e.g., RSA or DSS)? Again, I find no code
> points in given in the DOI.  Are there any references to the
> mechanics of the actual allowable algorithms (i.e., is there anything like a
> "here's how to use DSS with IKE" document?)

Appendix A specifies different magic numbers for RSA signatures and DSS 
signatures. Also, section 5.1 (the actual signature-based authentication 
method) mentions the encoding differences for each. Again, the DOI will
not help you with IKE negotiation issues. Those are wholly contained in
the IKE document.

> Perhaps it's late in the cycle to be raising this type of question, but I've
> got a feeling that IKE's level of precision in the recent draft is
> fuzzy enough that there will be many opportunities for non-interoperable
> implementations to arise.

Is this recent draft worse than the previous ones? Am I becoming more fuzzy
as time goes on? I sure hope not. Most of the changes from 6 to 7 were
editorial and were supposed to make things _more_ clear. In fact, all but
one (the IANA Considerations change) were hashed out on this list so I'd
be surprised and disappointed if they actually increased the fuzz.

It's a complicated protocol and you're right, there's lots of opportunity
to do something wrong. There are quite a few independent, interoperable
implementations though.

  Dan.
References: