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

IKE Loose Ends?



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?

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?

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?

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?)

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.
____________________________
Charles A Kunzinger (kunzinge@us.ibm.com)
TCP/IP Technology Management, JDGA/501, RTP
Phone: Tieline 8-444-4142 ,  External 1-919-254-4142
Fax: Tieline 8-444-6243,  External 1-919-254-6243
VM:  IBMUSM27(KUNZINGE)





Follow-Ups: