"wendy" <[EMAIL PROTECTED]> writes:
> Since the Registrar verifies that the target in the ReqUri and the
> target in the digest-uri reference the same resource, the proxy must
> not modify the ReqUri before the message arrives on the
> Registrar. Right?
You've correctly grasped the problem. This can happen in HTTP too,
which is why 2617 (sec. 3.2.2) describes the digest-uri parameter:
digest-uri
The URI from Request-URI of the Request-Line; duplicated here
because proxies are allowed to change the Request-Line in transit.
In section 3.2.2.5 it goes on to say:
The authenticating server must assure that the resource designated by
the "uri" directive is the same as the resource specified in the
Request-Line; if they are not, the server SHOULD return a 400 Bad
Request error. (Since this may be a symptom of an attack, server
implementers may want to consider logging such errors.) The purpose
of duplicating information from the request URL in this field is to
deal with the possibility that an intermediate proxy may alter the
client's Request-Line. This altered (but presumably semantically
equivalent) request would not result in the same digest as that
calculated by the client.
Note that it says that the two uri values should both refer to the
same resource, not that they are the same string. Both
'sip:[EMAIL PROTECTED]' and 'sip:[EMAIL PROTECTED]' (and many other
possibilities) refer to the same resource, but they would produce
different hash values.
In SIP, the request URI is so mutable that I'm not sure that one can
come up with a general solution to doing this check. On the other
hand, if your server is generating good (unpredictable) nonce values,
and validating them (ensuring that the nonce value in the retried
request is one it generated recently for this requestor), then I can't
think of an attack that could exploit the ability to modify the request
uri (which doesn't mean there isn't one).
--
Scott Lawrence
Pingtel Corp.
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
