On 23-10 15:52, Maxim Sobolev wrote:
the above is true if dialog was established by local user. in case the dialog was established by foreign user and that foreign user sends another, in-dialog request, then ftag will be equal to from tag.
so i implemented a function that checks if ftag is equal to either from or to tag, but didn't find it very useful after all. such test namely adds very little value to just checking if the request has to tag and dropping the ones that don't and are not send by or to a local user.
It should be relatively easy to do it - upon startup SER can generate some random string and then, when INVITE arrives, calculate one-way
hash > using this value and some other parameters that must persist during the > dialog - e.g. Call-Id, From tag etc, then inserting it as a parameter > into the Record-Route field. Then we can always check is the mid-dialog > request should be serviced by us.
yes, i too have suggested that we do something like that. this kind of scheme, however, has no protection over faking new requests or replays if someone gets hold of one real request.
Yes, that's true, but it IMHO is impossible to do something about that. In real world, however, it is very unlikely that a complete stranger will be able to get somehow real request, to do this he should be able to sniff communication channel between UA and proxy, in this case even digest-based auth mechanism would be pretty weak.
also, if one gets hold of several real requests, then it would be possible to figure out what the key was unless the key changes often enough. so i have been wondering, if such mechanism is worth implementing.
Not quite. If cryptographically-strong hashing function is used then it would be almost impossible to figure out server's portion of the key, even if attacker will be able to sniff channel during extended period of time.
To prevent replay attacks, the hash would have to be calculated also over To tag. The hash should contain To tag because it is generated by remote party and thus the possible "attacker" can't predict it's value.
This also means we would have to update the Record-Route header field when processing 200 OK, which complicates things a bit.
If we don't add To tag, then it would be really easy to use same hash for other requests as well provided that you use the same From tag.
Another problem is that the hash can't have limited life-time because we don't know how long the session is going to take, so it will be possible to relay such messages forever.
However, there is another problem that comes on my mind -- how such Record-Route parameters would affect interoperability. Given the large amount of negative feedback I got because of lr=on and using r2 parameter mostly during Sip-its, I predict that including many (and quite long parameters) could cause interoperability problems.
Due to presence if strict routers in the wild, we can't make them header field parameter (i.e. parameters behind >), becuase strict routers will put the Route header field into Request-URI stripping of all header field parameters.
If we make them URI-parameters (i.e. before closing >), can we make sure that other implementations will be able to handle such Request-URI ? (Maybe I am too paranoid, but my experience is not very good).
I agree with Maxim that figuring out the secret key would be pretty hard.
Jan.