Hmmm... I have seen SBCs out there that remove the authentication header as well and not all SBCs generate authenticate challenges (for example, they rely on a softswitch later on to do it). Also, there is the issue of a change in Nonce in the middle of the call when a new request gets a challenge with "stale=true".
I'm not sure we can refrain from introducing a new value generated by the SBC. > -----Original Message----- > From: Dan Wing [mailto:[EMAIL PROTECTED] > Sent: Friday, July 13, 2007 3:45 AM > To: Gilad Shaham; 'Hans Persson' > Cc: [email protected]; [EMAIL PROTECTED] > Subject: RE: [Sip] SIP Identity using Media Path > > > Dan Wing Wrote: > > > > > > Section 4.1, item about Contact: > > > > > > > > > > > > How can the Contact header usefully be used in the > > > > > > signing process? An > > > > > > SBC along the message path will happily replace it. > > > > > > > > > > I have removed that in -01 (which isn't yet published, of > > > > > course). There > > > > > was some thought it was necessary, but I agree it should be > > > > > removed from the signature. > > > > > > > > > > On a similar note, I am considering removing CallId from > > > > > the signature. > > > > > Oftentimes the Call Id value contains an IP address (in > > > > > dotted decimal > > > > > or hex), and an SBC or B2BUA may also want to rewrite such > > > > > a CallId. I > > > > > have made a note of that in -01 so this can be discussed. > > > > > > > > I thought about that as well, but apparently I forgot about > > > > adding it to > > > > my mail. I think it would be a good idea to take Call-ID out as > > > > well. > > > > > > Ok, thanks. > > > > > > > I agree with this, but keep in mind that the call-id serves as a nonce > > in RFC 4474. It might require introducing a new header/parameter to be > > the nonce. > > Thanks for that reminder. You're right, and I agree that having the > authentication service add its own nonce is the best way to do it; such > a nonce need only be a random number, as it's already qualified by the > authentication service's domain (and certificate). Thus, SBCs won't > need to also destroy it. I'll include that in my working revision > to sip-identity-media. > > -d _______________________________________________ Sip mailing list https://www1.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
