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:
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
