Hi Kai, Fischer, Kai wrote: >>>> This issue is totally independent from E.164 >>>> >>>> >>> Not fully. SBCs may exchange the domain part of the E.164 >>> >> SIP URI, which >> >>> causes a break of the RFC 4474 signature. With email-style >>> >> URIs a simple >> >>> exchange is not possible. >>> >>> >> This is true but this applies to SIP Identity in general and not to >> E.164 number usage with SIP Identity only. >> Hence, I would not tie it to this discussion. >> > > My point was, that with E.164 an intermediary SBC is able to exchange > the domain part without a possibility on the terminating side to > recognize the change. > With email-like SIP URIs the domain change is not > possible or only with a hack.
I see what you mean. The issue is that John, in one of his other mails, wants to add this relationship between the E.164 number and the corresponding domain. If you do not create this relationship then there are attacks possible and SIP Identity is just not the right mechanism since there is a domain that asserts certain properties and they just don't exist in this specific case. Bad luck. > Two cases need to be differentiated: > -SBC modifies SDP: This results in a necessity to create a new SIP > Identity signature and a change of the domain part in the From header > (valid for both types of SIP URIs email and E.164) > -SBC modifies From header field only: This is applicable to E.164 only > and as far as I have recognized from the past discussions a real world > behavior > > But in general there was the claim that SIP Identity does not work to well with SBCs. Dan wrote a draft about it. >>> >>> >>>> I don't like the idea of requiring DTLS-SRTP to provide proof of >>>> possession of the keying material. >>>> >>>> >>> It is also the other way round. If you use DTLS-SRTP to >>> >> encrypt RTP, the >> >>> terminating domain is interested where the call originates >>> >> from and in >> >>> which domain the SRTP connection is terminated. DTLS-SRTP is not >>> initially used as mean to establish an identity rather than as the >>> initial aim to encrypt RTP. >>> >>> >> I understand the need to know who the end points are. However, tying >> DTLS-SRTP is not a good idea since it >> a) increases the liklihood that SIP identity never get's >> deployed (since >> it is suddently far more complex than before) >> b) SIP identity is used also as a identity mechanism in areas >> where no >> media is exchanged. >> > > Do you propose to not apply RFC 4474 for DTLS-SRTP fingerprint > protection and to rely on something different? > SIP Identity works nice in certain environments. The fields that are covered by the digital signature calculation in SIP Identity have not been chosen arbitrarily. When an SBC changes some of the protected fields then there are obviously problems. Imagine a mechanism that wouldn't compute a signature at all then SBCs could do whatever they want. Good for SBCs; not so good for security. Ciao Hannes > Kai > > >> Ciao >> Hannes >> >> >>> Kai >>> >>> >>> >>>> Ciao >>>> Hannes >>>> >>>> >>>> Elwell, John wrote: >>>> >>>> >>>>> SBCs do exist, often for good reasons that Hadriel has expanded on >>>>> already. I firmly believe that DTLS-SRTP will not be >>>>> >> deployable in a >> >>>>> meaningful way without addressing this problem. Concerning >>>>> >>>>> >>>> solutions, we >>>> >>>> >>>>> have drafts from Kai and Dan, or perhaps a merger of the >>>>> >> two somehow >> >>>>> would work. It also depends to some extent whether we are >>>>> >>>>> >>>> talking only >>>> >>>> >>>>> about email-style URIs or about E.164-based URIs too. >>>>> >>>>> John >>>>> _______________________________________________ >>>>> Sip mailing list https://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 https://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 https://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
