andres,
why is authentication done by ser not enough?
-- juha
Lets say we have 5000 subscribers. One of them signs up for and additional account with an SPA3000(FXO Port). If the SPA3000 does not authenticate the incoming INVITE, then any of our 5000 subscribers can authenticate with our SER and then use this guys FXO port on the SPA3000. The idea is that only his "authorized users" can use his FXO port. The SPA3000 has room for up to 8 accounts for digest authentication, so he can select up to 8 firends/family to use his personal gateway.
Hope this is a bit more clear.
andres,
how about selecting the gw in ser based on caller's domain?
-- juha
Juha Heinanen wrote:
andres,
how about selecting the gw in ser based on caller's domain?
There is just one domain (all our subs belong to one domain). And the gateways are the SPA3000 which register dynamically as simply another UA. So gateways cannot be thought of as in the traditional sense. Even if they had static IPs, it would be a nightmare to manage say 1000 FXO personal gateways.
The way this works for example is a sub purchases 2 accounts. Account 1000 is for UA1(ATA186 for example) and account 1001 is for the FXO1(Sipura 3000). Both are separate hardware devices located in different places(and both register with SER). UA1 places a call to 1001, the FXO port will answer and give him local dial tone. UA1 then passess DTMF digits to the local telco attached to the FXO1. But the sub does not want anybody on our network to access line 1001, just those predefined on the FXO1 username/password digest definition (inside the SPA3000 config).
UA1 (1000) ------>SER--------->FXO1 (1001) ----> PSTN
There are other ways to authenticate the caller like via a PIN or Caller ID. But we are trying to see if digest authentication is also possible.
-- juha
This is an interesting problem. I would venture to say that if you did NOT authenticate for those calls that you pass to a spa-3000, then that would work... that is, if your SERPROXY doesn't authenticate.
is it possible that the problem is trying to authorize twice...once for your UAC<->SERPROXY and then the UAC<->SERPROXY<->UAS(SPA3000)
Can you have multiple credentials in the same SIP packet? Seems like it should work...
Sorry, not much help I know. Do you have a packet trace?
---greg
On Aug 9, 2004, at 3:39 PM, Andres wrote:
Juha Heinanen wrote:
andres,
how about selecting the gw in ser based on caller's domain?
There is just one domain (all our subs belong to one domain). And the gateways are the SPA3000 which register dynamically as simply another UA. So gateways cannot be thought of as in the traditional sense. Even if they had static IPs, it would be a nightmare to manage say 1000 FXO personal gateways.
The way this works for example is a sub purchases 2 accounts. Account 1000 is for UA1(ATA186 for example) and account 1001 is for the FXO1(Sipura 3000). Both are separate hardware devices located in different places(and both register with SER). UA1 places a call to 1001, the FXO port will answer and give him local dial tone. UA1 then passess DTMF digits to the local telco attached to the FXO1. But the sub does not want anybody on our network to access line 1001, just those predefined on the FXO1 username/password digest definition (inside the SPA3000 config).
UA1 (1000) ------>SER--------->FXO1 (1001) ----> PSTN
There are other ways to authenticate the caller like via a PIN or Caller ID. But we are trying to see if digest authentication is also possible.
-- juha
-- Andres Network Admin http://www.telesip.net
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Greg Fausak www.AddaBrand.com (US) 469-546-1265
Greg Fausak wrote:
This is an interesting problem. I would venture to say that if you did NOT authenticate for those calls that you pass to a spa-3000, then that would work... that is, if your SERPROXY doesn't authenticate.
I'll give this a try and let you know.
is it possible that the problem is trying to authorize twice...once for your UAC<->SERPROXY and then the UAC<->SERPROXY<->UAS(SPA3000)
Could be, but I am unsure if this would be a SER limitation or SIP limitation.
Can you have multiple credentials in the same SIP packet? Seems like it should work...
Sorry, not much help I know. Do you have a packet trace?
The packet trace reveals that the SPA3000 challenge is being swallowed by SER. What I mean is, this 401 is not being sent back to UA1 so there is nothing to see in this part of the leg. The 401 being sent back by the SPA3000 looks as normal as a 401 being sent back by SER to a user upon an INVITE. I can certainly grab these traces again tonight and send them to you.
---greg
Greg Fausak wrote:
This is an interesting problem. I would venture to say that if you did NOT authenticate for those calls that you pass to a spa-3000, then that would work... that is, if your SERPROXY doesn't authenticate.
is it possible that the problem is trying to authorize twice...once for your UAC<->SERPROXY and then the UAC<->SERPROXY<->UAS(SPA3000)
Can you have multiple credentials in the same SIP packet? Seems like it should work...
SIP allows multiple credentials in one request. These credentials differ in the realm string. So using the same realm for 2 hops does not work as long as the hops are not synchronized in producing the nonce. Maybe it can work if the proxy uses proxy-authentication and the SIPURA uses www_authentication.
Nevertheless I don't have any glue why ser blocks the 401 response from the SIPURA. Please post a SIP message dump.
regards, klaus
Sorry, not much help I know. Do you have a packet trace?
---greg
On Aug 9, 2004, at 3:39 PM, Andres wrote:
Juha Heinanen wrote:
andres,
how about selecting the gw in ser based on caller's domain?
There is just one domain (all our subs belong to one domain). And the gateways are the SPA3000 which register dynamically as simply another UA. So gateways cannot be thought of as in the traditional sense. Even if they had static IPs, it would be a nightmare to manage say 1000 FXO personal gateways.
The way this works for example is a sub purchases 2 accounts. Account 1000 is for UA1(ATA186 for example) and account 1001 is for the FXO1(Sipura 3000). Both are separate hardware devices located in different places(and both register with SER). UA1 places a call to 1001, the FXO port will answer and give him local dial tone. UA1 then passess DTMF digits to the local telco attached to the FXO1. But the sub does not want anybody on our network to access line 1001, just those predefined on the FXO1 username/password digest definition (inside the SPA3000 config).
UA1 (1000) ------>SER--------->FXO1 (1001) ----> PSTN
There are other ways to authenticate the caller like via a PIN or Caller ID. But we are trying to see if digest authentication is also possible.
-- juha
-- Andres Network Admin http://www.telesip.net
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Greg Fausak www.AddaBrand.com (US) 469-546-1265
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Finally figured this out...answers inline:
Klaus Darilion wrote:
Greg Fausak wrote:
This is an interesting problem. I would venture to say that if you did NOT authenticate for those calls that you pass to a spa-3000, then that would work... that is, if your SERPROXY doesn't authenticate.
Good guess. When we disabled the failure route (see below) and SER authentication, the call was completed as expected. The 401 came back all the way to UA1 and it resent the INVITE with the proper credentials for the SPA3000.
Nevertheless I don't have any glue why ser blocks the 401 response from the SIPURA. Please post a SIP message dump.
SER blocked the 401 because we had a failure route associated with that route block. The purpose was to send calls to voicemail in case of some failure/timeout. The 401 was treated as a failure so it was never forwarded to UA1. I disabled the "t_on_failure", and now the 401 did reach back to the UA1. The UA1 would then redo the INVITE with the proper credentials for the SPA3000, but now SER would block and send back a 407 since we have a proxy_authorize on INVITES, and the credentials had already been modified. So now it is very clear that this is not possible. What had me stumped was the t_on_failure deal that was blocking the 401 response.
In any case we can now move on and implement security via other methods.
Thanks for the help!
On 09-08 20:16, Andres wrote:
SER blocked the 401 because we had a failure route associated with that route block. The purpose was to send calls to voicemail in case of some failure/timeout. The 401 was treated as a failure so it was never forwarded to UA1. I disabled the "t_on_failure", and now the 401 did reach back to the UA1. The UA1 would then redo the INVITE with the proper credentials for the SPA3000, but now SER would block and send back a 407 since we have a proxy_authorize on INVITES, and the credentials had already been modified. So now it is very clear that this is not possible. What had me stumped was the t_on_failure deal that was blocking the 401 response.
Modified ? It should add them. According to the specification it is possible, if there are 2 digest challenges (distinguished by realm) in a response then the user agent should generate two digest replies if it has credentials for them and put them in the new message.
SER will pick one of the digest headers, SIPURA should pick the other one and the message will get through.
Jan.
Jan Janak wrote:
On 09-08 20:16, Andres wrote:
SER blocked the 401 because we had a failure route associated with that route block. The purpose was to send calls to voicemail in case of some failure/timeout. The 401 was treated as a failure so it was never forwarded to UA1. I disabled the "t_on_failure", and now the 401 did reach back to the UA1. The UA1 would then redo the INVITE with the proper credentials for the SPA3000, but now SER would block and send back a 407 since we have a proxy_authorize on INVITES, and the credentials had already been modified. So now it is very clear that this is not possible. What had me stumped was the t_on_failure deal that was blocking the 401 response.
Modified ? It should add them. According to the specification it is possible, if there are 2 digest challenges (distinguished by realm) in a response then the user agent should generate two digest replies if it has credentials for them and put them in the new message.
SER will pick one of the digest headers, SIPURA should pick the other one and the message will get through.
It should but it doesn't. Once it gets challenged by the 401 it forgets all about the previous challenge with the 407. In other words the new INVITE only has the digest reply to the new 401.
Jan.
On 10-08 02:11, Klaus Darilion wrote:
SIP allows multiple credentials in one request. These credentials differ in the realm string. So using the same realm for 2 hops does not work as long as the hops are not synchronized in producing the nonce. Maybe it can work if the proxy uses proxy-authentication and the SIPURA uses www_authentication.
No, the trick with proxy-authentication and www-authentication will not work. You have to either syncronize the nonce validation or use distinct realms.
The question is how widely are multiple credentials within a single SIP message supported in existing implementations. I saw many implementations that give up after second 401 or 407 even if there is a new challenge in the reply.
Jan.
Andres writes:
There are other ways to authenticate the caller like via a PIN or Caller ID. But we are trying to see if digest authentication is also possible.
yes, you could check by ser that caller's number is not faked and then authenticate in the gw based on the number.
-- juha
-
Andres -
Greg Fausak -
Jan Janak -
Juha Heinanen -
Klaus Darilion