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

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





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 should
be a reference to RFC 2409.

2. (Grammar & style) Section 3.2 lists 3 exchanges (Main mode, aggressive mode,
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. (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) Encryption
with El-Gamal, and 7) Revised Encryption with El-Gamal.

4. I do not recall any discussion on the mailing list about adding the two newly
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 to
RSA encryption?

5. In the formulas in Section 4.1 for I-digest and R-digest,the identity fields
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 included.
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?

5. I would prefer to see a slightly expanded definiton for SKEYID_e: "the keying
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 not
for user traffic.

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.

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 of
"Nofitication Exchanges".

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

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 vague
to be of use, and is really delivng into policy issues.  I am perhaps a little
more rigid than Tim--I think that the last two paragraphs of section 3.2 should
be deleted in their entirety, as it is not in the scope of the IKE spec to
define acceptable policy.





____________________________
Charles A Kunzinger (kunzinge@us.ibm.com)
Network Security Product Development, Dept JEUA,, RTP
Phone: Tie 8-444-4142 ,  External 1-919-254-4142
Fax: Tie 8-441-7288,  External 1-919-543-7288





Follow-Ups: