[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] What 4474 signs part-3 [was: Proposal to Revise RFC 4474]
> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> Behalf Of Hadriel Kaplan
> Sent: Freitag, 18. April 2008 22:42
> To: Cullen Jennings; Dean Willis
> Cc: SIP IETF; jon.peterson at neustar.biz
> Subject: [Sip] What 4474 signs part-3 [was: Proposal to
> Revise RFC 4474]
>
> ...
>
> So... I propose that once again the originator of the request
> be given an option: it can sign the MIME body, or not, based
> on its preference. This can be done in another parameter or
> param value of the Identity-Info header, similar to the
> Contact one proposed in part-2 of this thread; and again this
> parameter does not need to be signed itself because forging
> it or removing it implicitly breaks the signature calc
> anyway. The authenticator can likewise decide if it wants to
> accept a request with this parameter or not.
I think the flexibility of elements covered by a (RFC4474bis) signature
is an interesting idea. RFC 4474 shall be applied for different
scenarios and therefore the set of elements which needs to be signed
vary. For the protection of the DTLS-SRTP fingerprint only a few
elements need to be signed. However, the flexibility causes also some
interoperability issues like B expected header field x to be signed
whereas A doesn't sign it. The risk exists that both parties fall back
to the least common denominator (all mandatory elements), which is not
applicable resp. secure for all intended scenarios. So it could be
useful to define some RFC4474 signature profiles. These profiles are
also extendable for future use cases without a need to revise RFC4474bis
again.
Kai
>
> The semantics of this are such that the authenticator is
> saying "me.com verified user foo at me.com generated this
> request with these To, From, and Date, but not necessarily
> the SDP." This would be useful for spam avoidance, but not
> much more. (just as 4474 arguably is)
> If a srtp fingerprint is also signed, then it means a lot more.
>
> Alternatively, we could just recommend that such an
> originator simply send offerless-Invite's, since that is
> perfectly legal in 4474 and avoids this issue. But somehow I
> don't think that would be such a good idea. ;)
>
> -hadriel
> _______________________________________________
> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org for new developments on the application of sip
>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip