Subject: [Sip] R-REUSE, media-security-requirements

From: "Dan Wing" <[email-masked]>
Date: Thu, 7 Feb 2008 08:57:11 -0800

In draft-ietf-sip-media-security-requirements-02, I changed the following
requirement from MAY to MUST:

   R-REUSE  The media security key management protocol MUST support the
         re-use of a previously established security context, and
         implementations SHOULD implement the re-use mechanism.

A discussion of this requirement appears in Section 4.6 of the document,
http://tools.ietf.org/html/draft-ietf-sip-media-security-requirements-02#secti
on-4.6

Does anyone have equipment that they would implement this feature in?  In the
past, I have heard that some embedded devices (intelligent SIMs) could benefit
from key re-use.

Would it be reasonable to soften this requirement back to a MAY?

-d

_______________________________________________
Sip mailing list  http://www.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: Hannes Tschofenig <[email-masked]>
Date: Thu, 14 Feb 2008 11:40:01 +0200

Hi Dan,

MUST specify, SHOULD implement and MAY use seems fine for me.

I can imagine that not only end hosts would benefit from this mechanisms.

There are two mechanisms that offered slightly different functionality 
regarding this security context reuse, namely
* Re-use of a previously established security context based on state 
that has been established by both end points
* Re-use of a previously established security context by caching 
security context only on the client side.

I can imagine that both approaches are useful in certain scenarios. The 
requirement does not differentiate these two cases.

Ciao
Hannes

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 15 Feb 2008 17:32:37 -0800

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Thursday, February 14, 2008 1:40 AM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [Sip] R-REUSE, media-security-requirements
> 
> Hi Dan,
> 

So far you're the only person to respond to my email.  I had asked for
feedback because I had received push-back on the requirement to store state
from previous sessions, because such storage weakens the security of the
system by destroying perfect forward secrecy.  PFS is a 'must be able to
support' requirement in the document right now.  Any thoughts on this
requirements collision?

> There are two mechanisms that offered slightly different 
> functionality regarding this security context reuse, namely

On the second bullet, I assume you are referring to RFC5077 ("TLS Session
Resumption without Server-Side State")?

> I can imagine that both approaches are useful in certain 
> scenarios. The requirement does not differentiate these two cases.

Should the requirement be reworded to differentiate between those two cases?

-d

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 16 Feb 2008 12:17:39 +0200

Hi Dan,

> support' requirement in the document right now.  Any thoughts on this

I would like to comment on PFS:

The definition of the PFS in the Handbook of Applied Cryptography says:

"A protocol is said to have perfect forward secrecy if compromise of 
long-term keys
does not compromise past session keys."

Now, there is only the question what "long-term key" means in this context.

Hence, I am not so sure that PFS is destroyed with the ability to store 
session state. Furthermore, both parties can decide not to use it.

> Resumption without Server-Side State")?
Yep

> Should the requirement be reworded to differentiate between those two cases?
I would at least indicate that there are two forms of caching with 
somewhat different properties here.

Ciao
Hannes

> -d
>
>
>   
>> Ciao
>> Hannes
>>
>>
>>
>>
>> Dan Wing wrote:
>>     
>>> In draft-ietf-sip-media-security-requirements-02, I changed 
>>>       
>> the following
>>     
>>>    R-REUSE  The media security key management protocol MUST 
>>>       
>> support the
>>     
>>> A discussion of this requirement appears in Section 4.6 of 
>>>       
>> the document,
>>     
>>> Does anyone have equipment that they would implement this 
>>>       
>> feature in?  In the
>>     
>>> past, I have heard that some embedded devices (intelligent 
>>>       
>> SIMs) could benefit
>>     
>>> from key re-use.
>>>

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 17 Feb 2008 10:38:36 -0800

> Sent: Saturday, February 16, 2008 2:18 AM
> To: Dan Wing
> Cc: [email-masked]

A DTLS-SRTP implementation would have both the server and client
cache the TLS Session Id, and remember the Session Id between
phone calls.  This means the TLS security parameters and keys, 
and thus the SRTP key (which is derived from the TLS security
parametersa and keys), are remembered between phone calls.  

As far as I am aware, there is no guidance for how long (hours)
this information is expected to be retained.

> session state. Furthermore, both parties can decide not to use it.

If _either_ party stores the information, compromise of that
device (the one which stored the information) destroys PFS.  So 
even if I have configured my device to not store such information, 
whoever I'm calling might not have configured it that way.  There 
is no mechanism, currently, to negotiate or communicate if you
want the remote party to cache TLS session information.  Perhaps
RFC5077 could be used as the negotiation mechanism, such that
if both sides implement RFC5077 they are agreeing to caching
session information.  I am not too interested in RFC5077's
ability to have one side (the TLS client) store the state, but
rather I am interested in a negotiation mechanism such that
both sides agree to break PFS.

> somewhat different properties here.

Suggestions?

I am now leaning towards something like this; I am now leaning
towards MAY because no-one has said this feature is necessary
for equipment they envision in the field:

   R-REUSE, a system MAY describe how to cache state between
            SRTP sessions in order to reduce CPU processing for
            future calls.  Note that such caching destroys PFS.

   R-CACHING, if a system does implement R-REUSE, both peers
            MUST agree to such caching.

Thoughts?

-d