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

Re: 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.

ok. 

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

ok.

> 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.

No, it really means "repudiability". Perhaps you didn't read far enough
into the document. Section 5.2 explains this concept, as does the SKEME paper
itself and I recommend you read it as well (check out the references).

> 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.

ok.

> 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".

I don't understand what you mean by "the definition in the ISAKMP draft
applies simultaneously". 

> 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.

Your not getting something for nothing. You're just getting the amount
of keying material you need. I'm not a cryptographer either but cryptographers
have looked at this technique and not raised any red flags. This does not 
lessen or weaken the keying material (nor does it strengthen it) but it does 
impose strong mixing requirements on the prf. Which reminds me: 11.3 should
mention that requirement when requests for magic numbers for hash or prf are
made.

> 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.

Well, actually, it's nroff but that in no way excuses its lackadaisical
attitude toward productive labor. I'll raise this with its representitive
at the International Brotherhood of Document Formatters.

  Dan.