[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [BLISS] draft-ietf-bliss-shared-appearances:Provisioningconsiderations
On Wed, Jul 22, 2009 at 10:26 PM, Alan Johnston<alan at sipstation.com> 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: bliss-bounces at ietf.org on behalf of Francois Audet
>> Sent: Thu 7/16/2009 3:13 PM
>> To: Alan Johnston
>> Cc: bliss at ietf.org
>> 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
>> BLISS at ietf.org
>> https://www.ietf.org/mailman/listinfo/bliss
>>
>>
>
> _______________________________________________
> BLISS mailing list
> BLISS at ietf.org
> https://www.ietf.org/mailman/listinfo/bliss
>
--
Jason