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

Re: More comments on draft-ietf-ipsec-ike-00.txt

On Tue, 01 Jun 1999 17:58:16 EDT you wrote
> 
> Here are a few comments that I found when I read through the subject draft:
> 
> 1. Reference "HC98" is not listed in the section 11.  I assume that this shou
>ld
> be a reference to RFC 2409.

Right! Thanks for spotting that. Forgot my own RFC.

> 2. (Grammar & style) Section 3.2 lists 3 exchanges (Main mode, aggressive mod
>e,
> and quick mode).  Then it obliquely refers to 3 more, which are not listed.  
>I'd
> prefer to see an explicit listing of the other three: New Group, Acknowledged
> Informational, and Unacknowledged Informational.

3.2 describes attribute negotiation. I don't see what you're referring to.

> 3. (Grammar & Style) Section 2.5 mentions 4 "distinct methods of
> authentication", but only explicitly names two of them.  Again, I'd prefer to
> see all methods listed.    From perusing Appendix A, I beliive that there are
> actually 7 distinct methods: 1) preshared key, 2) DSS Signature, 3) RSA
> Signature, 4) Encryption with RSA, 5) Revised Encryption with RSA, 6) Encrypt
>ion
> with El-Gamal, and 7) Revised Encryption with El-Gamal.

Only 2? Section 2.5 says:

      There are four distinct methods of authentication in IKE: authentication
      with pre-shared keys, authentication with digital signatures, and two 
      methods of authentication using public key encryption.

Preshared keys is one, digital signatures is one, and two methods of public
key encryption. That's 4. It mentions 4 because that's what's described in
section 6.1. 6.1.1 is Main Mode and there are 4 distinct methods of
authentication (6.1.1.1 through 6.1.1.4). Similarly for 6.1.2.

> 4. I do not recall any discussion on the mailing list about adding the two ne
>wly
> defined authentication methods that are based on use of El-Gamal, which is
> listed as a "SHOULD" in the section 3.1. What was the rationale for doing so?
> And is there a reference to El-Gamal or a comparison of its merits relative t
>o
> RSA encryption?

It came up during a thread with John Gilmore. Patent issues prevented a
free implementation of IPSec/IKE from using RSA and El-Gamal is a fine way
to address that need. Also, PGP 5.0 has El-Gamal keys and since it's possible
to pass a PGP "certificate" it seems to make sense to have a well-defined
way to do this.

Do you have a problem with El-Gamal?

> 5. In the formulas in Section 4.1 for I-digest and R-digest,the identity fiel
>ds
> are shown as ID_i1 and ID_r1.  But in RFC 2409, the equivalent terms were
> IDIDii_b and IDir_b, indicating that the ISAKMP generic header was not includ
>ed.
> Hence, I believe that the draft should have used notiation IDi1_b and IDr1_b.
> Was it the intent in the new draft to explicitly inlcude the ISAKMP generic
> header in these digests?

That was an oversight on my part which was pointed out by Shawn Mamros.
You should grab the -01.txt version of the draft.

> 5. I would prefer to see a slightly expanded definiton for SKEYID_e: "the key
>ing
> material used to protect  the confidentiality of IKE messages"  makes it a
> little clearer that this keying material is used just for IKE messages and no
>t
> for user traffic.

OK, I'll add "of IKE messages."

> 6. In section 6 (Quick Mode), the formula for the HASH( ) values uses the RFC
> 2409 notation (IDci and IDcr).  This should be changed to IDi2 and IDr2.

Oops. I'll fix that. Thanks.

> 7. (Nomenclature) Since they are described in the body of 6.4, 6.4.1,  and 6.
>4.2
> as "informational exchanges", it would be clearer to change the heading of
> section 6 to read "Informational Exchanges" rather than its current wording o
>f
> "Nofitication Exchanges".

OK.

> 8. Appendix A lists Additional XCHG values for Quick Mode, New Group Mode, an
>d
> Acknowledged Informational.  Shouldn't there also be a value to denote
> Unacknowledged Informational?

It's the ISAKMP Informational exchange. Perhaps that should be mentioned
in 6.4.1. And I should probably mention in 6.1.2 that Aggressive Mode uses 
the ISAKMP Aggressive Exchange type.

> 9. I agree with Tim Jenkins' previously posted comment relative to section 3.
>2,
> "attributes with negotiable ranges".  The current text, as written, is too va
>gue
> to be of use, and is really delivng into policy issues.  I am perhaps a littl
>e
> more rigid than Tim--I think that the last two paragraphs of section 3.2 shou
>ld
> be deleted in their entirety, as it is not in the scope of the IKE spec to
> define acceptable policy.

It's not saying what acceptable policy is, just what acceptable negotiation
can be. There were a few people who just assumed that if Alice could success-
fully initiate to Bob that therefore Bob must also be able to successfully
initiate to Alice and if that didn't happen Alice was at fault.

I asked Tim so I'll ask you too: if you're configured to offer blowfish with
a 128 bit key and someone offers you blowfish with a 256 bit key what do
you do? What do you do when you're configured to offer group 2 and someone
offers you group 5? 

Also, if you feel that this should be removed in its entirety then how
do you feel about section 4.5.4 of RFC2407? Is that an unacceptable foray
into defining what acceptable policy can be?

  Dan.
References: