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

comments on draft-ietf-ipsec-isakmp-oakley-06.txt

The table of contents does not give the full names of the sections
within 5.  Each says what phase it is part of, and I would have found
that useful in the TOC.

The TOC entries for Appendices should have mentioned what was in each.

Section 1, in describing SKEME says:

   [Kra96] (SKEME) describes a versatile key exchange technique which
   provides anonymity, repudiability, and quick key refreshment.

I don't know SKEME, but claiming repudiability seems odd.  Perhaps
"non-repudiability" is meant.

Section 3.2 describes notation:

      IDx is the identity payload for "x".  x can be: "ii" or "ir" for
      the ISAKMP initiator and responder respectively during phase one
      negotiation; or "ui" or "ur" for the user initiator and responder
      respectively during phase two.  The ID payload format for the
      Internet DOI is defined in [Pip97].

I have posted notes about Identification Payload issues.  The correct
term appears to be "Identification Payload", not identity payload.

I think that the definition in the ISAKMP draft [MSST97] applies
simultaneously (in the IPsec DOI) or only (in the ISAKMP DOI).  The
term "Internet DOI" seems misleading; I'd use "IPsec DOI".

Section 5.5 describes how to cook up more keying material, if it is
needed:

   For situations where the amount of keying material desired is greater
   than that supplied by the prf, KEYMAT is expanded by feeding the
   results of the prf back into itself and concatenating results until
   the required keying material has been reached. In other words,

I'm not a cryptographer, but...  This sounds like something for
nothing.  What are the cryptographic implications of generating extra
keying material this way?  I think that the document should address
this question.

Appendix A, under group description:

   - Group Description
      default 768-bit MODP group (section 6.1)      1

      alternate 1024-bit MODP group (section 6.2)   2
      .sp
      EC2N group on GP[2^155] (section 6.3)         3
      .sp
      EC2N group on GP[2^185] (section 6.4)         4

     values 5-32767 are reserved to IANA. Values 32768-65535 are for
     private use among mutually consenting parties.

Indented troff commands don't work.

Hugh Redelmeier
hugh@mimosa.com  voice: +1 416 482-8253
Follow-Ups: