Ongoing discussion
No dependencies.
This was my initial description in an email exchange. I will rewrite later and make it more precise...
It is always a problem to balance the need for relatively short register expiry (like 10 min) to avoid NATi [1] restarts etc to render to UA unavailable and longer expiry to avoid loading the server (on large scale setups) with lots of authentications. My idea is basically the following: Would it be possible to configure let's say x minutes expiry on registers on the UAs, but when storing location set x+1 as expiry in location. When a reREGISTER message arrives, the location will still be in user location, can be looked up and if some parameters matches (again, this is where my idea touches the above discussion) like call-id or maybe received ip and port, the expiry time is just updated to new x+1 minutes. If no match, a regular authentication is attempted.
The problem here is the validity of digest
credentials in the message. When challenging a user agent the server
creates nonce. Nonce is a hash that helps to seed the algorithm that
creates digest response in the user agent. The nonce string contains
expires value with default expires set to one minute. Thus if the
server generates a nonce and sends it to the user agent, the user
agent has one minitu to create the digest response and send a new
REGISTER messagee containing digest credentials. After one minute the
server would refuse the credentials as stale and issue new challenge.I wouldn't even let the reREGISTER go by the authentication check if the
registration already existed. Something like this:
if(registered("location")) {
if(source ip and source port == received of usrloc) {
update expiry to new x+1 (NOT save, as contact may be a spoof)
break;
}
}do regular authentication for new source ip:port or if not already
registered.
What if I send a REGISTER request with spoofed IP address containing
expires=0 ? This way anyone could unregister contacts of other users,
because if there was no authentication then the contacts would be
removed immediately from the database. Digest authentication, on the
other hand, would make sure that the source IP and port of the message
is reachable (not true for spoofed source IPs).Yes, good point. expires=0 should not be allowed and should be challenged.
The idea is to implement a REGISTER refresh, thus ONLY REGISTER messages
where we have an existing, matching location and where the received ip and
port for the message matches the received ip and port on record should be
excepted. Of course, such a refresh can be spoofed, but as the location
should NEVER be changed for a refresh, there is not really an issue with
that.
This means that the REGISTER would never be challenged if the REGISTER
comes from the already registered ip:port. Thus, the REGISTER is just a
refresh of received parameter.
What is your main concern ? Database queries of the need for extra
round-trip-time when using digest authentication ?No, the refresh will also have a DB write to update expire, so that's not
really the issue. You will gain something in reducing the number of messages
to parse and challenge, but I don't think that alone is a lot to gain from.
If you use radius auth, you probably have large radius servers that handle different
types of requests. If it is possible to implement a refresh, we will offload
a lot of auth radius requests (over udp) to a (more) local DB update in
mysql. As the radius servers receives requests from many different places, I
would prefer to keep application-specific requirements (refreshing REGISTER
messages every x minutes) to the local server (which is cheaper and easier
to scale).
The cost of extra
communication for digest can be eliminated using longer expires value
in nonce. Then the UA would simply supply the same set of credentials
as in the last registration and no challenge would be needed.
Furthermore we would need to hash the value of contact into nonce, to
make sure that long-lived credentials can only be used for one
particular contact URIi [2].Hm, haven't thought about that. Could be a way to implement it. I have been
thinking about creating a new function in register: