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

[Sumit Garg <sgarg at cedarpointcom.com>]

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