I'm afraid that I disagree with the apparent concensus, and
agree with Russ.
"Applications which desire replay prevention should carefully
consider what it is they are trying to accomplish and
design accordingly. "
Excellent advice, but unfortunately very rarely followed.
In my experience, standards are very often misapplied and misused
by people who were not involved in the original discussions and don't
appreciate the subtleties. This seems like a case where this is all too
likely.
(BTW, as someone who has only casually been follwing these
discussions, and hasn't even read the text yet, I admit to falling into
that category of people who may not appreciate the subtleties.
My apologies if I am misreading something.)
Signing time in this context would presumably not be viewed as a
secure timestamp -- in particular I assume that no representatations are
made about its correctness (accuracy relative to UTC).
But on the other hand, except in the possible case of a stuck clock
(which is still fail safe), it is extremely unlikely to repeat, even if the
system clock is adjusted backwards. And if it does repeat, that
simply means that a message would be rejected as a replay
attack.
I would be perfectly happy with suggesting that signing time always
be used, but I suppose you could have a CHOICE of signing time or some
nonce. Creating a good nonrepeating nonce may be even harder,
however.
Bob
Russ Housley <housley(_at_)spyrus(_dot_)com> writes:
Unless an application making use of SignedData includes a specifically
formatted field that includes replay prevention, any application protocol
using SignedData will be open to replay.
The CMS specification can reamin silent on this issue, or we can recommend
a simple patch. Why not recommend that the signing time attribute always
be used?
When no authenticated atributes are included, this solution will not help.
In this case, the best we can do is a paragraph in the security
considerations section.
Thoughts?
I'd rather the spec remain silent on this issue.
Timestamps aren't a very good fix for replay prevention.
Applications which desire replay prevention should carefully
consider what it is they are trying to accomplish and
design accordingly.
-Ekr
--
[Eric Rescorla Terisa Systems, Inc.]
"Put it in the top slot."
Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
bjueneman(_at_)novell(_dot_)com
"Architects, like prophets and saints, are
usually years ahead of their time. For this
reason they are often difficult to live with
at home."