[VOIPSEC] SIP B2BUA and Digest Authentication using

Sat Nov 5 17:17:37 CST 2005

Baruch Sterman wrote:

>I think we can work fairly easily to accommodate this scenario as well.
>Instead of passing the cleartext information (including Digest string and
>without the password, of course) from proxy to Radius Server and getting an
>OK that the digest string matches, we can pass the cleartext information
>including nonce to the Radius Server and retrieve the digest string to send
>back to the User Agent. 
>
>Make sense?
>
>Baruch
>
>-----Original Message-----
>From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
>Behalf Of Dan Wing
>Sent: Thursday, November 03, 2005 6:46 PM
>To: 'satyam tyagi'; Voipsec at voipsa.org
>Subject: Re: [VOIPSEC] SIP B2BUA and Digest Authentication using
>
>  
>
>>-----Original Message-----
>>From: satyam tyagi [mailto:satyam_tyagi at hotmail.com] 
>>Sent: Thursday, November 03, 2005 8:35 AM
>>To: dwing at cisco.com; Voipsec at voipsa.org
>>Subject: RE: [VOIPSEC] SIP B2BUA and Digest Authentication using
>>
>>Hi Dan,
>>
>>Yes, but it is still easy to ring the phones, spoofing INVITE 
>>as SIP server, unless the phone challenges the INVITE.
>>
>>There are some techniques to use line-id etc (As some snome 
>>phones do) but not once you know line id again this is possible.
>>    
>>
>
>TCP would help.  TLS-over-TCP would help even more.
>
>In the absence of that, you could rotate the line-id every few hours (and
>re-register), only accept Invites from the same IP address as your SIP proxy
>(akin to what a symmetric NAT imposes on its outbound connections), and make
>sure the network follows RFC2827 practices (Network Ingress Filtering).
>
>-d
>
>  
>
I am jumping in the middle here, but have briefly browsed some previous 
messages here so bear with me if I am repeating something.

If TLS is utilized, and assuming that all calls are originating within a 
closeed SIP domain (where Trusted root CA certs are implemented on the 
clients and the clients have client side certificates issued by the 
Trusted root then it shouldnt be an issue at all.

The backend communication between the radius server and the SIP UAS 
(separate from the communication between any B2BUA and the SIP UAS) 
could further be protected, assuming a geographically distributed RADIUS 
environment, by requiring IPSec or SSL VPN's between the SIP UAS and the 
RADIUS server.

I do not see an issue with implementing certificates at this level, 
given that the Trusted CA could reside with the networking domain of the 
SIP UAS (Provider maintained network). If a user is going to sign up 
with a SIP provider the implementation of such a scheme should be 
feasible and implemented in this way, latency should be able to be 
controlled.

Now permitting communications between the trusted SIP domain and 
untrusted is a bigger stretch and will definately require TRUST 
relationships from other providers (note that I am not considering 
private individuals in this context at this time, but that will come).

Just my two cents...I am going to go read and see how much I may have 
mucked here.

I am also reading the radius digest draft with interest. 

The main thing is that the end result may very well follow with the good 
old KISS methodology.

Chris

>>Satyam
>>
>>
>>
>> 
>>
>>	
>>________________________________
>>
>>	From:  "Dan Wing" <dwing at cisco.com>
>>	To:  "'satyam tyagi'" <satyam_tyagi at hotmail.com>, 
>><Voipsec at voipsa.org>
>>	Subject:  RE: [VOIPSEC] SIP B2BUA and Digest 
>>Authentication using
>>	Date:  Thu, 3 Nov 2005 08:01:08 -0800
>>	MIME-Version:  1.0
>>	Received:  from sj-iport-5.cisco.com ([171.68.10.87]) 
>>by mc7-f1.hotmail.com with Microsoft SMTPSVC(6.0.3790.211); 
>>Thu, 3 Nov 2005 08:01:12 -0800
>>	Received:  from sj-core-3.cisco.com ([171.68.223.137]) 
>>by sj-iport-5.cisco.com with ESMTP; 03 Nov 2005 08:01:10 -0800
>>	Received:  from dwingwxp ([10.32.240.195])by 
>>sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id 
>>jA3G15Wr018942;Thu, 3 Nov 2005 08:01:05 -0800 (PST)
>>	> That is the case when the SIP server wants to challenge
>>	> the phone.
>>	>
>>	>
>>	> The other half is when Phone challenges the SIP server.
>>	
>>	Authentication-Info allows that mutual authentication.  
>>See RFC3261 section
>>	22.4.
>>	
>>	-d
>>	
>>	
>>	
>>
>>
>>    
>>
>
>_______________________________________________
>Voipsec mailing list
>Voipsec at voipsa.org
>http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>
>
>
>_______________________________________________
>Voipsec mailing list
>Voipsec at voipsa.org
>http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>
>
>  
>