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

Re: Exchanging Certificate Chains

At 10:27 AM 7/16/97 -0400, Dave Mason <dmason@tis.com> wrote:

>>  But, nothing in isakmp-oakley-v<whatever>.txt should be interpreted as
>>forcing a certain order on payloads. You can send the nonce before the key
>
>I would have to differ with you here.  The first paragraph of Section 4
>states that the order in which the payloads are processed is defined by
>the specification and the sections that describe the exchanges generally
>go like this:
>
>   .....  Mode is defined as:
>
>   HDR, A, B, C
 [ ... ]
>I think that the MUST used here was meant more for the fact that ID
>payloads for both of the endpoints must be sent so that the appropriate
>security policy may be selected.  [The order was already defined in
>the exchange definition.]
>
>-dave

and,
At 10:12 AM 7/16/97 -0700, Daniel Harkins <dharkins@cisco.com> wrote:

>Well since I wrote those words I think I know what I meant. Granted, 
> [ ... ] Hopefully isakmp-oakley-v4 will be more clear.

The contributers to this subject seem to agree that one should be able to
accept payloads in arbitrary order, with the possible exception of the
Quick Mode Hashes 1 and 2; no one has screamed in objection.  Probably most
implementers, being Real Programmers, have written their receive code this
way.

But the current state of affairs is isakmp-oakley v-03 says or implies
otherwise as Dave Mason points out.  Dan H. makes a general statement that
he doesn't mean it to be that way.  So people are saying they think they
know how it is; but we will keep needing to raise the question if we are
not assured by the spec or by a definite statement about what's going into it.

Can we hope that isakmp-oakley-v4 will confirm these points:

  o An exchange defines those payloads which are required in each
    message.  In general each message description does not imply required
    order of payloads; any required ordering is explicitly noted in the
    particular exchange description.

  o In Quick Mode, the Hash 1 and Hash 2 payloads must appear immediately
    before that remaining part of the message which is to be hashed.

    [Expecting this would be the least objectionable tack; I expect at
    least some implementors have, reasonably enough, depended on this
    ordering, which is in fact explicit in isakmp-oakley v03, and I see
    no argument for a change at this point.]

    [The words about leaving out the pad added by encryption roundup I
    am presuming would stay the same.]


I would also like to suggest some clarification in the isakmp-oakley
discussion of the QM Hash 1 and 2.  First it states clearly that the hash
is over the message; but then it says that in other words the hashes are:

  HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDui | IDur ])

  (and updated per Harkins mail Fri, 16 May 1997 accepted by the 
   participants in the June Detroit interworking tests:)
  HASH(2) = prf(SKEYID_a, M-ID | Ni | SA | Nr | [ | KE ] [ | IDui | IDur ])

I think notation here is troublesome to the reader, because all those
symbolics for payloads usually mean the content without the header, and in
this case they mean including the header, which I think it confuses the
issue.  And in the new statement of Hash 2, the symbolic "Ni" means content
only, while "Nr" means with header, so Dan Harkins assured me in response
to private mail.  Might it be done something like this:

    HASH(1) = prf(SKEYID_a, M-ID | <remaining message body>)
    HASH(2) = prf(SKEYID_a, M-ID | Ni | <remaining message body>)

  Where message body is all message bytes following the hash payload,
  through the last payload; these payloads must include:
        SA | Ni [ | KE ] [ | IDui | IDur ]


As long as I'm asking for things, I'll also request something to this
effect on QM first and second messages:

  o If the initiator of QM sends KE, an SA with PFS is being established,
    and the responder must return KE.  Otherwise no KE's should appear.

  o If the initiator of QM sends [ IDui | IDur ], then the responder must
    include them in the response.  Otherwise no ID's should appear.


John Burke <jburke@cylink.com>
Cylink, Sunnyvale CA