Yes, that's right. We could also include the value of Contact header
field into nonce. That way it won't be possible to reuse the same nonce
for another Contact header field.
nonce string will be generate for Contact: A, another user agent trying
to reuse the digest credentials with Contact: B to steal incoming calls
will fail because the contact in nonce and Contact in the SIP message
will not match.
Jan.
On 02-08 11:03, Antanas Masevicius wrote:
hi,
As i understand it would be virtually impossible to replay with proper
timestamp for certain request and with required ip, but nevetheless it
would be possible to fake required source_ip and in that case my patch
(posted earlier on this list) wouldn't help too. Adding source ip to nonce
would remove additional administrative burden, isn't it? Probably the only
advanatage of authorization by entering IP adresses separately would be
independance from any other encryption or authorization mechanisms which
could be used with SIP.
Antanas
On Sun, 1 Aug 2004, Jan Janak wrote:
> No, but I have this on my todo list. Currently it is possible to re-use
> credentials generated by user agent A also by user agent B provided that
> it can sniff the SIP messages and it is fast enough to send another
> message including the sniffed credentials. The credentials have limited
> lifetime (1 minute by default) so after 1 minute they cannot be re-used
> in other SIP messages.
>
> If you have two user agents connected to the same hub (so that they can
> see SIP messages of each other) then you can modify one of them to steal
> the calls to the other user agent using sniffed digest credentials.
>
> I am thinking about including the source IP address of the SIP message
> and some other header fields (Contact) into nonce to eliminate this
> weakness.
>
> Jan.
>
> On 28-07 15:00, zolia(a)z1sys.com wrote:
> > hello,
> >
> > is it possible to do source ip authentication besides normal
> > www_authorize() for every user account?. This, as i understand, should
> > prevent from intercepting credentials and later faking sip message to
> > bypass www_authorization ? Or maybe there are some other counter measures
> > against such fraud?
> >
> > Does src_ip comes directly from ip layer? If so, i could probably use this
> > to check with some external database (ie. ser subscriber)?
> >
> > Antanas
> > NTT
> >
> > _______________________________________________
> > Serusers mailing list
> > serusers(a)lists.iptel.org
> >
http://lists.iptel.org/mailman/listinfo/serusers
>