> -----Original Message----- > From: Dan Wing [mailto:[EMAIL PROTECTED] > Sent: Dienstag, 8. April 2008 23:10 > To: Fischer, Kai; [email protected] > Cc: Elwell, John > Subject: RE: [Sip] Migration from E.164 to email-style SIP URIs > > > -----Original Message----- > > From: Fischer, Kai [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, April 08, 2008 6:32 AM > > To: Dan Wing; [email protected] > > Cc: Elwell, John > > Subject: RE: [Sip] Migration from E.164 to email-style SIP URIs > > > > Let's explore your proposal further regarding the problems > > discussed in > > the other two threads (sorry for mixing the email threads > > now, but it is > > close related to the migration proposal): > > > > First problem: Weak PSTN numbers > > Proposal > > - Don't include the E.164 number in the signature if it was received > > from the PSTN (certificate fingerprint is still protected > and bound to > > the email-style SIP URI of SIP Gateway provided in 'email-identity') > > - Include the E.164 number in the signature if not received from the > > PSTN > > That's independent from the concrete signing mechanism > except that RFC > > 4474 does not cover the new header field > > > > Second problem: SBC traversal > > - If both identity information are signed it conflicts with SBCs > > modifying SDP information and therefore need to change the > domain part > > of the SIP URI in the From header as well > > - If only the email-identity information is signed (by the > Wing/Kaplan > > or Fischer draft), intermediary SBCs should not break the signature. > > However, the E.164 number has PSTN security level only as > > assumed above, > > but email-style is bound to certificate fingerprint and signed > > > > An straw man extension to your proposal, which mitigates the SBC > > traversal problem is to create two signatures. One signing the > > email-identity including the certificate fingerprint and which is > > protected end-to-end. The other one covering the From > header field and > > which might re-newed during traversal by intermediaries. The > > disadvantage are for sure two signing processes. > > Sure, you could do that. > > But at this point in time it seems there is little value in > RFC4474 signatures if there are SBCs on the path; if the SBCs > support RFC4474, they will have to re-sign the identity and > will have to re-write the From. In such a situation, RFC4474 > provides protection of SIP requests being modified between > the Service Provider (running the SBC) and yourself. You can > achieve identical protection from the same attack by doing > SIP-over-(D)TLS with that same SBC, and not bothering with > RFC4474 (or RFC4916) to/from that SBC.
I agree to that. The other way around, the second signature provides additional benfit (end-to-end property) if RFC 4474 is used in that scenarios for some reason. But that depends if the outcome of the 'RFC 4474 and SBC traversal' email thread is - Yes, there is a problem which need to be fixed or - No problem, RFC 4474 is applicable in these scenarios Kai > > (I would even go so far to say that, in the same case with > your provider running an SBC, running SIP-over-(D)TLS to that > provider is superior to RFC4474 because SIP-over-(D)TLS > protects SIP responses; neither RFC4474 or RFC4916 protect > SIP responses.) > > -d > > _______________________________________________ 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
