Why? It makes quite sense to me. That Bob authenticates itself does not mean that there can't be a MiM afterwards during session setup. As far as I can see, Registrar based solution would address this concern only if Registrar/Proxy are the same entity and a TLS connection is kept alive from beginning of the registration process and is used for further sessions where Bob is callee.
Thanks, Tolga > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of vimal > srivastava > Sent: Thursday, October 13, 2005 4:37 PM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [email protected] > Subject: RE: [Sip-implementors] Authenticating an incoming SIP call > > > actually it does not make any sense to authenticate him again > thru invite, > its just message flooding. if bob is registered ( and authenticated), why > would softswitch authenticate him in invite. using expire duratioon of > registration can be fixed, after which softswitch can force bob > to register > again. > > > > From: "vimal srivastava" <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED], [email protected] > Subject: RE: [Sip-implementors] Authenticating an incoming SIP call > Date: Thu, 13 Oct 2005 16:06:32 -0400 > > there is no way you can send invite and authenticate bob defined in sip. > this is how it works > if softswitch is giving call to bob, then bob must be registering with > softswitch (else how softswitch would deliver the call, using some > registrar? again its fine) > when register happens at that time softswitch should authenticate bob. at > this time whatever contact bob tells, thats authenticated > address. and when > softswitch wants to deliver invite it does not need to authenticate bob > again. > cheers > > > From: "Shikhar Sarkar" <[EMAIL PROTECTED]> > To: <[email protected]> > Subject: RE: [Sip-implementors] Authenticating an incoming SIP call > Date: Thu, 13 Oct 2005 15:33:04 -0400 > > Vimal, > > I mean the case say (just an example) Alice is calling Bob, > > ISDN IAM Invite > Alice---------SS7---------->Softswitch------------>SIP phone(Bob) > > Now if the Softswitch wants to authenticate Bob as a valid user for this > call, how to do it using SIP? [Assume Bob is already registered with the > Softswitch, but the Softswitch wants to authenticate Bob per call] > > I think I am missing something very fundamental. Otherwise, I suppose this > is the most basic question for any telecom guy. > > Shikhar > > -----Original Message----- > From: vimal srivastava [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 13, 2005 3:18 PM > To: [EMAIL PROTECTED]; [email protected] > Subject: RE: [Sip-implementors] Authenticating an incoming SIP call > > > you mean to say proxy is sending one invite to a UAC? and Proxy wants to > challenge this UAC also? > UAC--------INVITE------------> PROXY-------------------INVITE----------UAS > Proxy can challenge only UAC not UAS. > UAS can challenge proxy as well as UAC > this is how it works. > now UAC can include authorization header in the invite itself so that it > does not receive 401 from UAS or 407 from proxy > thats what i meant. > cheers!! > > > From: "Shikhar Sarkar" <[EMAIL PROTECTED]> > To: <[email protected]> > Subject: RE: [Sip-implementors] Authenticating an incoming SIP call > Date: Thu, 13 Oct 2005 14:15:27 -0400 > > Vimal, > > Did you get my question? I am talking about an incoming call scenario when > say the SIP proxy sends Invite to the SIP client (e.g. my SIP phone). The > SIP proxy wants to challenge the SIP client to make sure the call is not > delivered to a fake entity. How does your comment fit in this scenario? > > Or I am missing some basic understanding? Please help. > > Shikhar > > -----Original Message----- > From: vimal srivastava [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 13, 2005 1:54 PM > To: [EMAIL PROTECTED]; [email protected] > Subject: RE: [Sip-implementors] Authenticating an incoming SIP call > > > yes, registration alone does not suffice. in the invite you should include > authorization header. if you dont then, you can be challenged by 401 or > 407. more over you might end up encoding multiple authorization > header for > different nodes in between :) > cheers > > > > From: "Shikhar Sarkar" <[EMAIL PROTECTED]> > To: <[email protected]> > Subject: RE: [Sip-implementors] Authenticating an incoming SIP call > Date: Thu, 13 Oct 2005 13:01:39 -0400 > > Guys, > > This discussion is going interesting. One group of people responded saying > "Yes possible", and the other said "It's not". The end result is that I am > very confused now. > > I am trying to figure out a way in which I can challenge the SIP endpoint > before delivering a call to it. The endpoint has already registered and > passed authentication. But, when delivering an incoming call, if I want > additionally to make sure that the call is not delivered to a spoofer, is > there a way to authenticate the user? I am talking about something similar > that happens in the cellular world. > > Shikhar > > -----Original Message----- > From: Asheesh Joshi [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 13, 2005 1:57 AM > To: 'Shikhar Sarkar'; [email protected] > Subject: RE: [Sip-implementors] Authenticating an incoming SIP call > > > Yes... Authentication challenge can happen for any request except > CANCEL and ACK > > Authentication mechanism is the Digest Authentication. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Shikhar > Sarkar > Sent: Thursday, October 13, 2005 4:25 AM > To: [email protected] > Subject: [Sip-implementors] Authenticating an incoming SIP call > > Guys, > > Is there a way to authenticate a SIP user for incoming call scenario such > as: > IAM Invite > SS7----------->Softswitch------------->WiFi SIP device > > The WiFi SIP device of course has already registered with > Softswitch. But is > that enough to assume that there is no clone/eavesdropper? I am wondering > why I always see 401/407 challenges always opposite to the direction of > Invite. Is there a way to include Authentication challenge in the Invite > itself? > > Please throw some light. > > Shikhar > > _______________________________________________ > Sip-implementors mailing list > [email protected] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > _______________________________________________ > Sip-implementors mailing list > [email protected] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
