Subject: Re: [BLISS] draft-ietf-bliss-shared-appearances:Provisioningconsiderations

From: Sumit Garg <[email-masked]>
Date: Tue, 21 Jul 2009 14:09:00 -0700 (PDT)

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-masked] on behalf of Francois Audet
Sent: Thu 7/16/2009 3:13 PM
To: Alan Johnston
Cc: [email-masked]
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

---

From: Alan Johnston <[email-masked]>
Date: Wed, 22 Jul 2009 15:26:32 -0500

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, 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:
> _______________________________________________
> BLISS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bliss
>
>

---

From: Jason Fischl <[email-masked]>
Date: Tue, 28 Jul 2009 10:04:49 +0200

On Wed, Jul 22, 2009 at 10:26 PM, Alan Johnston<[email-masked]> wrote:
> 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...
>> Subject: Re: [BLISS]
>> draft-ietf-bliss-shared-appearances:Provisioningconsiderations
>>
>>
>> Finally, for the last case in your email, i.e.,
>> From/To/Http-digest-credentials = HelpDesk,
>> "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
>>
>>

-- 
Jason