On 22-10 22:36, Maxim Sobolev wrote: We discussed this some time ago, part of it is already implemented, Juha started to implement another part, but I don't know what is the current state. Here is a description: Before forwarding a mid-dialog request, a proxy would like to check that the dialog has been established using the proxy. To be able to do that, a piece information has to be inserted into INVITE message that can later help to identify the dialog. The only place in the SIP message where this can be done is Record-Route header field (because you can make sure that the the contents of the header field will be present in all subsequent requests). The proxy will mark the dialog by inserting ftag parameter into it's Record-Route header field, the ftag parameter will contain From tag. Later, when a mid-dialog request (for example BYE) comes, the proxy will do the following: - First it checks if From contains a domain the proxy is responsible for and if so, it will simply generate digest challenge and that's it. If the user is able to generate proper digest reply than he belongs to our domain and his requests will be forwarded. - If From doesn't contain a domain the proxy is responsible from then we can't use digest authentication--the sender wouldn't be able to generate proper reply. In this case the proxy compares To tag with ftag parameter value from it's Route header field. If they are same then the dialog was established using the proxy and we are done -- we can relay the request. The algorithm will also work with messages which do not establish a dialog like MESSAGE or OPTIONS because such message will have domain of our proxy either in From (we challenge) or in the Request-URI (processed automatically). Current implementation status is that the ftag part has already been implemented and Juha recently sent a message that he is working on a function that can do the comparison with To tag. The approach as described here won't prevent malicious users from using your proxy as a relay because they can forge the Route header field including ftag parameter, but it will prevent users that have "misconfigured" their user agents from using you as outbound proxy. To prevent also malicious users, some kind of cryptographic protection of the Route header field would be needed. This cryptographic protection is already implemented, but I have it in form of a patch and I haven't enough time yet to integrate and test it. Jan.

Maxim Sobolev writes: 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. 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. 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. -- juha

On 23-10 15:52, Maxim Sobolev wrote: 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.