13 jan 2011 kl. 10.02 skrev Iñaki Baz Castillo: > 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)). That would work, but maybe a warning header as well. Which would require an RFC. I don't like the idea of sending 200 OK to failed requests though, it kind of breaks my vulcan logic circuit.
/O _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
