On Wed, Jul 22, 2009 at 10:26 PM, Alan Johnston<[email protected]> wrote: > Hi Sumit, > > Yes, RFC 3261 is a bit confusing in this regard. We should get some > opinions from other SIP experts and registrars that have implemented 3rd > party registrations before deciding exactly how we should do it in this > case. > > I have always assumed that authentication in SIP is based on the From URI. > In SIP registration, the AOR being registered is the To URI. However,
This has always been my assumption as well. Robert, could you weigh in on this topic? > text in Section 10 does say that the authenticated identity is the To, which > is confusing. For a standard first party registration will have both the To > and From URIs the same, so it doesn't matter, but for a 3rd party > registration, it does matter. It seems to me requiring the authentication > credentials of the To URI for 3rd party registration defeats the whole > purpose of 3rd party registrations. > > Thanks, > Alan > > Sumit Garg wrote: >> >> It appears to me that the section 26.3.2.1 does not agree with section >> 10.3 of the same spec...as that(10.3) implies the asserted identity is >> derived from the From header (without challenge)but section 26.3.2.1 implies >> that the asserted identity is derived from the To header (with challenge)... >> Anyways, below implies (from 10.3)that the user should be authenticated >> and then the permissions for the AOR should be checked... >> Section 26.3.2.1 implies authentication based on info in the AoR to be >> registered against... >> >> 3.A registrar SHOULD authenticate the UAC. Mechanisms for the >> authentication of SIP user agents are described in Section 22. >> Registration behavior in no way overrides the generic >> authentication framework for SIP. If no authentication >> mechanism is available, the registrar MAY take the From address >> as the asserted identity of the originator of the request. >> >> 4. The registrar SHOULD determine if the authenticated user is >> authorized to modify registrations for this address-of-record. >> For example, a registrar might consult an authorization >> database that maps user names to a list of addresses-of-record >> for which that user has authorization to modify bindings. If >> the authenticated user is not authorized to modify bindings, >> the registrar MUST return a 403 (Forbidden) and skip the >> remaining steps. >> >> In architectures that support third-party registration, one >> entity may be responsible for updating the registrations >> associated with multiple addresses-of-record. >> >> From: [email protected] on behalf of Francois Audet >> Sent: Thu 7/16/2009 3:13 PM >> To: Alan Johnston >> Cc: [email protected] >> Subject: Re: [BLISS] >> draft-ietf-bliss-shared-appearances:Provisioningconsiderations >> >> >> I don't have a strong opinion one way or another, but I think >> the point is that we decide, and document it. >> >> It's not clear to me why the first method (3rd party authentication) is >> "a bad idea" and the second one (3rd party registration) is a good one. >> Can you clarify why it's bad? >> >> I *think* (I could be wrong) the 3rd party authentication would be >> supported >> by any UA today that supports a separate "Authorization name" (or "realm >> auth" or >> whatever it is called). In contast, I haven't seen many UAs supporting 3rd >> party registration. >> >> Furthermore, in 3261, your would assume that the username in the >> credentials >> be the same as the userinfo part of the To header (3261/26.3.2.1). In what >> you are >> describing here for 3rd party registration, in contast, you are using for >> the username, >> the userinfo of the From header. >> >> In other words, any way we choose to go, we are changing the way you'd >> normally expect >> authentication to work. >> >> Anyways, to summarize: I don't have a strong opinion. Just pick one, and >> document >> it in the draft. I think leaving it open to interpretation will cause >> interoperability >> issues. >> >> ---- >> >> PS: >> >> Finally, for the last case in your email, i.e., >> From/To/Http-digest-credentials = HelpDesk, >> we are in 100% agreement. That's also what we have done. We should >> describe it in the text. >> >> >> Forever, >> Sumit >> "The reasonable man adapts himself to the world; the unreasonable one >> persists in trying to adapt the world to himself. Therefore all progress >> depends on the unreasonable man." >> -- George Bernard Shaw >> >> >> _______________________________________________ >> BLISS mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/bliss >> >> > > _______________________________________________ > BLISS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bliss > -- Jason _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
