Hi Dan,
>> -----Original Message----- >> From: Hannes Tschofenig [mailto:[EMAIL PROTECTED] >> Sent: Thursday, February 14, 2008 1:40 AM >> To: Dan Wing >> Cc: [email protected] >> Subject: Re: [Sip] R-REUSE, media-security-requirements >> >> Hi Dan, >> >> MUST specify, SHOULD implement and MAY use seems fine for me. >> > > 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? > > 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. >> 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. >> > > On the second bullet, I assume you are referring to RFC5077 ("TLS Session > Resumption without Server-Side State")? > > Yep >> 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? > > 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 >> >>> 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-requi >> rements-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 PROTECTED] for questions on current sip >>> Use [EMAIL PROTECTED] for new developments on the application of sip >>> >>> _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
