> -----Original Message-----
> From: Hannes Tschofenig [mailto:[EMAIL PROTECTED]
> Sent: Saturday, February 16, 2008 2:18 AM
> To: Dan Wing
> Cc: [email protected]
> Subject: Re: [Sip] R-REUSE, media-security-requirements
>
> 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.
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.
> 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.
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.
> >> 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.
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
> 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
