> Hmmm... I have seen SBCs out there that remove the
> authentication header
You're referring to the RFC4474 Identity and Identity-Info headers? Or to
something else? Yes, I fully believe and expect SBCs and many B2BUAs would
remove those. There isn't much harm in removing them, though, especially
for an SBC, because the SBC's modification of the SDP's m/c lines will
invalidate the RFC4474 signature anyway.
> as well and not all SBCs generate authenticate challenges
> (for example, they rely on a softswitch later on to do it).
I don't follow; what do you mean by 'generate authenticate challenge'?
> 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".
What I intend on doing in the next version is extend Identity-Fingerprints
so it contains the nonce, something like this (highlighted with "<<"):
...
Identity-Fingerprints:
nonce=1234 <<<<<<<<<<
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
...
v=0
...
m=audio 54113 RTP/SAVP 0
a=setup:active
a=connection:new
a=fingerprint:SHA-1
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
The contents of the Identity-Fingerprints header (which contains
the nonce generated by the authentication service and the
a=fingerprint values from the SDP), is signed by the requestor's
authentication service (if an enterprise, that would typically
be your enterprise's authentication service; if you're using
a service provider, it's your SP's authentication service).
> I'm not sure we can refrain from introducing a new value generated by
> the SBC.
-d
> > -----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
