[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Calling the question: derived vs. explicit IV
> From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
> Please indicate where RFC-1829 supports "sequence number wrapping"?
>
> RFC-1829 doesn't. However, new implementations --- the ones which we
> are trying to get out the door and shipping quickly --- will have to
> deal with sequence number wrapping if we're worried about RFC-1829
> compatibility, since for manual keying your draft specifies that the
> sequence number starts at some random point (and wraps), whereas for
> automatic keying, the sequence number starts at zero, and doesn't wrap.
>
I don't understand. Is there some assumption in your answer that
sequence numbers starting at one (not zero) would somehow never wrap for
manual keying?
Exactly what protocol mechanism is proposed for manual keying to prevent
this from happening?
> > No so. The fielded units do not support key management. The assumption
> > which I'm making here is that manual keying will continue to use RFC
> > 1829.
>
> Are you saying that there will be two (or more) supported domains of
> interpretation, one for manual keying and another for Oakley/ISAKMP?
>
> DOI is a ISAKMP term. As such, it doesn't make sense for manual keying.
>
OK, "universes" is the term used earlier by Moskowitz.
And your next answer appears to indicate that yes, when there is vendor
and market interest in manual keying, it will be a different "universe",
and it will continue to be compatible with RFC-1829 and -1851.
> Are you saying that it will be the official policy of the IETF that
> RFC-1829 and its successors will advance to Internet Standard as the
> method to use for manual keying?
>
> That depends on whether there is any vendor and market interest in
> manual keying and backwards compatibility with the old boxes. I have
> been told that most vendors what to get away from manual keying as fast
> as they can. If there's no interest in manual keying, then we can let
> RFC-1829 either (a) not advance, or (b) go to historic. That however,
> is not a matter that this working group needs to decide now.
>
I'm confused by your answer. It's not?
It was my thought, and the thought of others with whom I have
corresponded, that your postings were introducing incompatibility with
RFC-1829 and -1851 for manual keying.
Manual keying is an absolute requirement in numerous situations. For
example, chicken and egg problems with otherwise insecure distributed
configuration of security parameters.
In my view, this entire question revolves around choosing the best
technical solution for manual configuration of DES and 3DES. And thus,
compatibility with RFC-1829 and -1851.
This straw poll is only talking about IVs within the DOI of
Oakley/ISAKMP?
I already have the sentence:
Alternative IV generation techniques MAY be specified when dynami-
cally configured via a key management protocol.
In which case, why not simply add a few sentences to ISAKMP-DOI saying
that an explicit IV is used?
> Is a MAC required or optional?
>
> The MAC is optional; however, if it isn't there, then obviously data
> integrity wasn't required or important. If data integrity is a
> requirement, then you should be using a MAC.
>
Since the MAC is optional, then anti-replay is optional. As the current
drafts assume.
And if anti-replay is optional, then sequence number checking is
optional, too. As the current drafts assume.
In short, we have arrived at the opposite assumption about sequence
number wrapping....
WSimpson@UMich.edu
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
Follow-Ups: