23 Oct
2003
23 Oct
'03
4:29 p.m.
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.
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, 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.
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. 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.