Re: IKE Loose Ends?
"Derrell D. Piper" <ddp@network-alchemy.com> Thu, 19 March 1998 17:42 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA19434 for ipsec-outgoing; Thu, 19 Mar 1998 12:42:37 -0500 (EST)
Message-Id: <199803191753.MAA29966@relay.hq.tis.com>
To: Charles Kunzinger <kunzinge@us.ibm.com>
cc: ipsec@tis.com
Subject: Re: IKE Loose Ends?
In-reply-to: Your message of "Thu, 19 Mar 1998 11:02:23 EST." <5040300013976010000002L002*@MHS>
Date: Thu, 19 Mar 1998 09:55:52 -0800
From: "Derrell D. Piper" <ddp@network-alchemy.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Charles, > 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? "Negotiation" means the use of the PRF attribute during the Phase 1 SA negotiation (see pg. 34). > 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? The reference to "MD5" and "SHA" are just names. The IKE draft consistently states, as you point out, that the HMAC versions are the ones that are used in IKE (see pg. 7). > 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? >From the IKE draft: 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. The value SKEYID is computed seperately for each authentication method. These correspond to the following sections as you note. > 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?) What is a code point? Section 5.1, for example, defines how the different signature algorithms (RSA vs. DSS) must be encoded by an IKE implementation (see pp. 10-11). The IKE draft is paired with the base ISAKMP draft and the IPSEC DOI. There are no other drafts describing additional interpretations or implementation mechanisms/tricks. Derrell
- IKE Loose Ends? Charles Kunzinger
- Re: IKE Loose Ends? Daniel Harkins
- Re: IKE Loose Ends? Derrell D. Piper
- Re: IKE Loose Ends? Sumit Vakil