> -----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 > > > > > > > That's an interesting proposal. I didn't get if your > intention is to > > > sign both headers (From header with E.164 and > > 'email-identity' header) > > > or only the email-based one. > > > > For the purposes of my straw-man, you can assume (a) we > have resolved > > all problems with signing E.164s in From, or you can assume > > (b) we have > > not resolved any problem with signing E.164 in From -- > either way, my > > proposal still provides benefit: the called party can use > the email- > > style address to establish end-to-end identity with the > calling party, > > and can use that to establish an end-to-end SRTP session (using a > > mechanism similar to your draft or the Wing/Kaplan draft). > > > 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 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
