Subject: [Sip] replays and SMIME

From: Michael Thomas <[email-masked]>
Date: Tue, 19 Feb 2002 06:57:23 -0800 (PST)

So I'm not terribly familiar with SMIME so I was
curious how replay detection was performed.  There
doesn't seem to be a specific section which talks
about it, but section 2.7.1 does talk about cipher
suite selection as well as timestamp handling,
which is I think is the relevant text. According
to the document, you are supposed to keep a list
of all of the known SMIME senders, their last
timestamp and their cipher suites. If you receive
something before the last recorded time stamp, you
should reject it.

So, on an el-cheapo hard drive this is probably
not much of an issue, but I don't think it would
work very well on a SIP UA which only has flash
memory. Also: I'm not sure I buy the mechanism
since reordering could come into play with SIP
(though it seems pretty unlikely with mail). In
any case, if we're going to have replay detection
for SMIME bodies, I think we're going to need a
better scheme here.

	 Mike

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Eric Rescorla <[email-masked]>
Date: 19 Feb 2002 07:14:05 -0800

Retransmitting, since I sent the first reply to Michael alone.

Michael Thomas <[email-masked]> writes:
> curious how replay detection was performed.
In general, S/MIME doesn't worry much about replay protection.

>In
I agree. What I had in mind was using essentially the same mechanism
that is use with Digest: a series of nonces that must be echoed in the
message to ensure freshness. The alternative, of course, is to use
sequence numbers a la IPsec, but this requires storage for each
client.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]
                http://www.rtfm.com/

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 19 Feb 2002 10:38:42 -0500

While limiting the time interval for replay via nonces is clearly a good
thing, most stand-alone devices will probably get a few dozen calls a
day, at most, and the ones I know already log those calls for user
convenience. Thus, I doubt that this is a big problem in practice, given
that the amount that needs to be logged is probably a few tens of bytes
per call (the Call-ID would do, in all likelihood). Beyond that, a Date
header that's more than a day out of whack is probably a good-enough
clue. There's no reason not to have SNTP on a UA - we don't have to
repeat the ISDN mistake where you buy a $500 ISDN phone and then have to
set the time manually.

---

From: Eric Rescorla <[email-masked]>
Date: 19 Feb 2002 08:01:47 -0800

> repeat the ISDN mistake where you buy a $500 ISDN phone and then have to
I'm thinking of a future where Digest has been displaced by 
S/MIME with a shared key. In this instance proxies would have
a lot of traffic and the storage requirements could be
substantial.

-Ekr

---

From: Michael Thomas <[email-masked]>
Date: Tue, 19 Feb 2002 08:25:42 -0800 (PST)

> repeat the ISDN mistake where you buy a $500 ISDN phone and then have to

   Uh, no. You're supposed to record it by public key
   which are, what, 128 bytes? Even the if you
   recorded it by DN, it would probably chew quite
   a bit more than 10's of bytes.

   In any case, this is an entropy problem; every
   call you get with SMIME would need to be
   recorded forever. I don't know what the current
   parameter flash sectors are today, but last I
   looked they were typically < 10kb. Not good.

	  Mike

---

From: Eric Rescorla <[email-masked]>
Date: 19 Feb 2002 08:29:52 -0800

>    looked they were typically < 10kb. Not good.
Well, you could always record by digest of public key instead of
DN or PK, which alleviates the problem some. But I agree with your
main point. Replay-detection systems must require only limited
storage on the recipient's side. This generally means nonces.

-Ekr

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 19 Feb 2002 11:36:04 -0500

>    recorded forever. I don't know what the current

Not true; if you read my message, you might note that I said that if you
assume even the most loose of clock synchronization constraints (one
day), you could automatically discard any message that's off by more
than a day.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 19 Feb 2002 08:56:50 -0800 (PST)

Eric Rescorla writes:
 > >    The main problem with nonces is that they add the
 > >    challenge, which amounts to another round trip. 
 > Yes. Of course, we've already sucked this up with Digest, so
 > it doesn't bother me that much.

   Right, though eliminating the need for a challenge
   would still be helpful even there. I don't know
   if you've seen the call flows with preconditions,
   etc, but the number of messages flying by is
   getting pretty horrendous.

 > >    Another way we could do this is to use
 > >    a Kerberos-like replay detection which requires
 > >    loose time synchronization. This retains the
 > >    ability to send signed data blindly. Given the
 > >    ability to reject things which are out of the
 > >    window, it reverts to the same behavior of
 > >    nonces, but if clocks are generally close you
 > >    wouldn't normally need the initial challenge.
 > I'm assuming you're thinking that you'd retain a list of all
 > messages received within the window?
 > 
 > This sounds like a reasonable approach.

   Yes, that's what Kerberos' replay cache presumes.
   Typically it's about 5 minutes worth. That should
   be pretty workable for UA's...

	     Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 19 Feb 2002 08:50:24 -0800 (PST)

> day), you could automatically discard any message that's off by more

   Um, Henning. It might help if you actually read
   the section. This is not what it says at all.

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 19 Feb 2002 08:47:10 -0800 (PST)

The main problem with nonces is that they add the
   challenge, which amounts to another round trip. 
   If you extended this for the middle-middle case
   (eg for caller ID), this starts looking pretty
   messy, and eliminates the ability to take
   advantage of one of the really nice features of
   public key crypto -- that is, you can sign
   something without knowing its ultimate
   destination. This is actually pretty useful in
   some cases, especially if the UA and/or proxy
   knows that some piece of data will need
   authenticated a priori.

		     Mike

---

From: Eric Rescorla <[email-masked]>
Date: 19 Feb 2002 08:51:31 -0800

-Ekr

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 19 Feb 2002 12:04:39 -0500

You said "forever", I said "that's not true", which you then confirmed
in the Kerberos case, for an even smaller window. I'm lost as to what
I'm missing.

---

From: Eric Rescorla <[email-masked]>
Date: 19 Feb 2002 09:12:15 -0800

>    getting pretty horrendous.
It looked pretty horrendous to me too :(

-Ekr

---

From: Michael Thomas <[email-masked]>
Date: Tue, 19 Feb 2002 09:13:30 -0800 (PST)

> in the Kerberos case, for an even smaller window. I'm lost as to what

   SMIME doesn't say anything about deleting entries
   of this list. It's assumed they be kept indefinitely.
   This is also tied up with cipher suite agreement.
   Read RFC 2633.

   As for use of a nonce or time based replay detection,
   those are potential ways of getting around this
   problem with RFC 2633 SMIME. They are not standard.

		Mike

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 19 Feb 2002 12:38:54 -0500

For SMTP, that makes sense, as SMTP messages can stick around for days,
if not longer. Nothing keeps us from modifying the replay detection
behavior for SIP, with its much shorter maximum message lifetimes
measured in seconds.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 19 Feb 2002 09:54:19 -0800 (PST)

> behavior for SIP, with its much shorter maximum message lifetimes

   The less loose you require clock syncrhonization,
   the more likely you are to have a time-skew
   rejection. This is the classic tradeoff with 
   Kerberos-like replay detection. In general,
   clock skew is the rule, not the exception.

   Also: there is no way currently to tell the
   other side of a clock skew error. With
   Kerberos, this is a necessary component since
   it allows for adaptation to clock skew. Any
   time-based replay detection in SIP must do 
   something similar. 

	     Mike