2011/1/13 Olle E. Johansson <[email protected]>:
> YOu're talking about "reject the request" - how do we reject the request
> based on policy after a successful authentication?
REGISTER ->
<- 401
REGISTER -> (correct credentials)
<- 403
What is wrong sending such 403 after successful authentication? First
authentication is performed, and then authorization.
> The RFC indicates to me that if the syntax is correct and we have
> authenticated that the request is authorized to bind to the AOR in the To:
> header (and follows the rules about SIPS) then we should save the contact
> regardless.
Of course I was speaking about a "local policy making sense" in which
the registrar rejects a REGISTER coming from untrusted clients and
containing a Contact URI whicih doesn't match the request source
address (or it could save the source addrress as location URI as many
registrars do).
But I insist: this behaviour cannot be "documented" in a RFC. It's
like the open relay: a SIP proxy accepting traffic from everywhere and
routing it according to normal SIP rules (Route headers, RURI...).
This is like the SPAM in SMTP world, but I'm sure it's not documented
in RFC 3261.
> Is there a way to say "Yes, you are authorized to this AOR but you are not
> allowed to use this Contact" ?
On another hand, replying 200 with no Contact header (or just the
previously existing locations of same AoR but ignoring the new one)
could work, but again, not documented as a mechanism.
> ...in a way so that the client UAC understands what's going on and can log a
> proper error.
For that I like more my second proposal (200 without REGISTER Contact URI(s)).
--
Iñaki Baz Castillo
<[email protected]>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
