[Top] [All Lists]

Re: Replay of CMS SignedData

1998-08-11 08:45:42
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

(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

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, 


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.


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. 


[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

"Architects, like prophets and saints, are 
usually years ahead of their time. For this
reason they are often difficult to live with
at home."

<Prev in Thread] Current Thread [Next in Thread>