[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IKE Loose Ends?
Charles,
Please see my comments below.
Sumit A. Vakil
3Com, Corp.
kunzinge@us.ibm.com on 03/19/98 10:02:23 AM
To: ipsec@tis.com
cc:
Subject: 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?
>> The hash function and the authentication method can be negotiated using
the appropriate attributes from the data attributes list in Appendix A of
the IKE draft. These data attributes are used in the transform payload
during SA negotiation. Both the ISAKMP and IKE drafts describe how to use
the various ISAKMP payloads during the negotiation phase.
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?
>> In IKE, the hash algorithms are always used in HMAC form (if the PRF is
not negotiated) to do the key and hash derivations. The only exception is
the hash of the certificate used with public key encryption based
authentication during phase 1. So I think that the document is ok here.
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?
>> Section 5 does enumerate the authentication methods: "Four different
authentication methods are allowed with either Main
Mode or Aggressive Mode-- digital signature, two forms of authentication
with public key encryption, or pre-shared key." And yes, the ways to use
the various authentication methods with Main mode and Aggressive mode are
described in sections 5.1 through 5.4.
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?)
>> Check out Appendix A of IKE. It defines the values that the
authentication method attribute can take. It includes DSS signatures and
RSA signatures.
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)