[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: problems with draft-jenkins-ipsec-rekeying-06.txt
Hugh,
I don't agree with your interpretation and I think you are missing the
point. The MUST NOT clause is not saying what you think it is saying,
"unique to" means "characteristic of", and, in the context of "randomly
generated", "unique" means "statistically unique" (i.e. collision
resistant).
However, I agree with Paul in this matter. Obviously, the RFC is
amphibologous enough to have confused you, so it should be amended to be
more clear.
Internet drafts are written in a mix of English and jargon; sometimes the
two languages overlap and it confuses people. Obviously, Dan knows what the
intent of the wording in the IKE RFC is; I don't see how you can argue with
that. Most of the rest of us figured it out as well.
BTW, imagine if we had to qualify "unique" as "statistically unique"
everywhere...
"Alice is probably the only one who can decrypt the message because only she
(or someone who randomly generated the same public key as she did) has the
private key."
"The hash proves that the message hasn't been tampered with (or at the very
least, that the original message was one of the very few 256 byte messages
that would have produced the same hash)."
"The responder must store all nonces that he ever generates. If he ever
happened to randomly generate a nonce that was used before then he could
fall victim to a replay attack."
Andrew
--------------------------------------
Beauty with out truth is insubstantial.
Truth without beauty is unbearable.
> -----Original Message-----
> From: D. Hugh Redelmeier [mailto:hugh@mimosa.com]
> Sent: Monday, July 17, 2000 11:07 AM
> To: Andrew Krywaniuk
> Cc: 'Tim Jenkins'; 'IPsec List'; 'Hugh Daniel'; 'John Gilmore'; 'Henry
> Spencer'
> Subject: RE: problems with draft-jenkins-ipsec-rekeying-06.txt
>
>
> | From: Andrew Krywaniuk <andrew.krywaniuk@alcatel.com>
> | Date: Thu, 13 Jul 2000 15:21:40 -0400
>
> | Hugh:
> |
> | > As noted the message ID in the ISAKMP header-- and
> used in the prf
> | > computation-- is unique to this exchange and MUST NOT
> be the same as
> | > the message ID of another phase 2 exchange which generated this
> | > informational exchange.
> | >
> | > This does not qualify "unique" in any way. It does
> clearly use the
> | > admonition "MUST NOT".
> |
> | As I mentioned several weeks ago, your statement here is
> misleading. The
> | "MUST NOT" clause only applies to the statement that the
> informational
> | exchange shoudn't use the same message id AS THE QM WHICH
> (PRESUMABLY)
> | CAUSED IT TO BE GENERATED.
>
> What I said about this quote from RFC2409 did not clearly communicate
> what I meant. Sorry. Let me try again.
>
> The sentence is best understood as two separate assertions.
>
> | > As noted the message ID in the ISAKMP header-- and
> used in the prf
> | > computation-- is unique to this exchange
>
> The Message ID of the exchange is unique.
>
> | > and MUST NOT
> be the same as
> | > the message ID of another phase 2 exchange which generated this
> | > informational exchange.
>
> The MUST NOT is reinforcing an implication of the first part: that the
> Message ID on an Informational Exchange won't be the same as the
> Message ID of another Phase 2 exchange which generated the
> Informational Exchange. This needs to be reinforced because sharing
> a Message ID in this case would help connect the Informational
> Exchange to the Phase 2 exchange that generated it.
>
> So this use of MUST NOT does not enforce uniqueness in general, only
> in this particular case. But it contradicts any interpretation
> that "unique" means nothing.
>
> There is still the use of "unique" that I pointed out in
> RFC2408. RFC2408
> "ISAKMP" 3.1 "ISAKMP Header Format" (near end) states that
> the Message ID
> must be unique, without further qualification:
>
> o Message ID (4 octets) - Unique Message Identifier used to
> identify protocol state during Phase 2 negotiations.
> This value
> is randomly generated by the initiator of the Phase 2
> negotiation. In the event of simultaneous SA establishments
> (i.e. collisions), the value of this field will likely be
> different because they are independently generated
> and, thus, two
> security associations will progress toward establishment.
> However, it is unlikely there will be absolute simultaneous
> establishments. During Phase 1 negotiations, the value MUST be
> set to 0.
>
> | As for your clear misinterpretation of the word "unique",
> let's go straight
> | to the source. Take a look at the passage I have blocked
> off and you will
> | see how the words "unique to" are commonly interpreted.
> |
> | According to Webster:
>
> | _______________________________________________________
> |
> | b : distinctively characteristic : PECULIAR 1 <this is not
> a condition
> | unique to California -- Ronald Reagan>
> | _______________________________________________________
>
> I'm having trouble applying this interpretation to the quote from
> RGC2409. Are you claiming that the quote means that only
> Informational Exchanges have Message IDs? That is easy to refute :-)
>
> Hugh Redelmeier
> hugh@mimosa.com voice: +1 416 482-8253
>
>
Follow-Ups:
References: