[Home]

Summary:ASTERISK-04855: 403 Forbidden in REGISTER violates rfc3261
Reporter:James Feeney (james nurealm net)Labels:
Date Opened:2005-08-18 16:08:59Date Closed:2011-06-07 14:10:12
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Registration
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Asterisk will respond with "403 Forbidden" to a REGISTER request from a
"User ID" that is not a configured sip.conf section header name, instead of
responding with "401 Unauthorized", and without ever waiting for an
"Authorization:..." header.  This Asterisk chan_sip.so SIP module REGISTER
behaviour is in violation of RFC 3261.

With User Agent Client devices, such as the Sipura SPA devices, which
distinguish between the "User ID" - which is like an email alias, and "Auth
ID" - which is like a login name, Asterisk will fail to properly register
the UAC device even though the authentication credentials are correct if the
user/peer URI/To/From name does not match an Asterisk sip.conf section
header.

Why this matters - for the new VoIP customer, registration authorization is
the only thing that matters and has to be right: server, authname, and
password.  Everything else - phone numbers, URI/To/From names, port numbers,
codecs,... these should all be "discovered" or negotiated by the User Agent
Server.

By asking for an Authorization header to authenticate a UAC, Asterisk can
lower the Service Provider administrative costs by eliminating the need for
any further administrator involvement in the UAC configuration process
_without_forcing_ the customer to use some contrived URI user name.


****** ADDITIONAL INFORMATION ******

Specifically, emphasis as in the original:

RFC 3261            SIP: Session Initiation Protocol           June 2002
22 Usage of HTTP Authentication
22.2 User-to-User Authentication

When a UAS receives a request from a UAC, the UAS MAY authenticate
the originator before the request is processed.  If no credentials
(in the Authorization header field) are provided in the request, the
UAS can challenge the originator to provide credentials by rejecting
the request with a 401 (Unauthorized) status code.

Notice that this does NOT say "by rejecting the request with a
403 (Forbidden) status code."

10 Registrations
10.3 Processing REGISTER Requests
...
When receiving a REGISTER request, a registrar follows these steps:
...
 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.
...
 5. The registrar extracts the address-of-record from the To header
    field of the request.

Notice that step 5 "extract" comes AFTER step 3 "authenticate".

3 Terminology
  In this document, the key words "MUST", "MUST NOT", "REQUIRED",
  "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
  RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
  described in BCP 14, RFC 2119 [2] and indicate requirement levels for
  compliant SIP implementations.

RFC 2119
3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
  may exist valid reasons in particular circumstances to ignore a
  particular item, but the full implications must be understood and
  carefully weighed before choosing a different course.

How does anyone expect a Service Provider UAS to recognize some random
new customer UAC without waiting for and authenticating the Authorization
header?  By forcing the customer to use a certain name?!  "I know your name
is 'Bill', but from now on you will use the name 'Sue', because...."  Well,
because somebody's software violates the SIP specification.  Yuck!

The VOIP-info.org site says this about "SIP config username":
http://www.voip-info.org/tiki-index.php?page=Asterisk+sip+username

"When Asterisk registers with another SIP proxy, the username is used in
digest authentication"

That, of course, has nothing to do with when Asterisk is acting as a
Registrar.  The site goes on to say:

"When asterisk boots, we have no information on a dynamic peer, a peer that
registers. In order to be able to place a call to the phone, Asterisk sends
an INVITE to username@defaultip."

That's nice for an in-house configuration, and pointless when the dynamic
peer is a customer using an unknown username from an unknown IP address.

Unfortunately, while Asterisk, and other User Agents, can function in both
client and server roles or modes, Asterisk often uses the same parameter
name, and even the same parameter, for different functions in different
roles.  This is not a problem when the role is explicit, but is a formula
for confusion when a parameter can have different roles in the same context.

At least two factors are always needed to correctly reference or specify the
meaning of the parameter here: 1) the channel interface, as in
"asterisk-SIP" or "the-other-guy-SIP", or more concisely, "My-SIP" and
"Their-SIP", and 2) the User Agent role or mode, as in "Server" or "Client",
or operatively, "Requires" and "Uses".  So, for "username", there are four
different parameters which could be named:

"My-SIP_Uses_username"      <->  "Their-SIP_Requires_username"
"My-SIP_Requires_username"  <->  "Their-SIP_Uses_username"

I notice that the Asterisk sip.conf parameter name "username=" is ignored
when Asterisk acts as a registrar, and that the UAC URI/To/From
"address-of-record" username - but conspicuously, not the IP address and not
the FQDN - corresponds to the Asterisk sip.conf section header name, as in
[<channel_name>].

Effectively, for the four parameters above, Asterisk has reason to use three
of these parameters, and uses the parameter names:

"username"                   <->  ""
"[<some-sip.conf-channel>]"  <->  "username"

Now _that_ must confuse a few people...


RECOMMENDATIONS

An RFC 3261 compliant Asterisk would use more expressive parameter names for
the authentication parameters, expressed in the order above as,

"username"  <->  ""
"authname"  <->  "defaultname"

or in a categorical order,

Parameter
Roles          My              Their
Client         username        defaultname
Server         authname        <null>

in combination with these changes:

1) Have the Asterisk channel name section header be just an arbitrary name,
which will be referenced by commands in extensions.conf, same as now.

2) Use the Asterisk parameter "username" exclusively to register Asterisk
with a remote registrar.

3) Create a new Asterisk parameter "authname", which is exclusively the
parameter used in combination with the Asterisk parameter "secret" for
Digest Authentication, as in RFC 3261 22.1 Framework, and 22.4 The Digest
Authentication Scheme.

Note that the administrator can set the Asterisk "authname" to whatever they
prefer, and either the UAC "User ID" or the UAC "Auth ID" may correspond to
this Asterisk "authname" value, as necessitated by the features and
functions of the UAC, which need be of no concern to Asterisk.

4) Create a new Asterisk parameter "defaultname" to be used exclusively in
combination with "defaultip" to form the default URI
"defaultname@defaultip".

The "defaultip" parameter name would be more appropriately named
"defaulthost" since it can take on both a FQDN or an IP address.

5) When acting as a registrar, specifically with the Asterisk parameter
configuration "host=dynamic", _always_ "authenticate the UAC", as
"RECOMMENDED" by RFC 3261.


Comments:By: Clod Patry (junky) 2005-08-19 00:12:27

I dont think that's major.
By: Mark Spencer (markster) 2005-08-19 00:15:26

This is just a configuration issue combined with your misunderstanding of RFC3261 and the 401 authorization.  By definition, when Asterisk says 403, it means 403:

21.4.4 403 Forbidden

  The server understood the request, but is refusing to fulfill it.
  Authorization will not help, and the request SHOULD NOT be repeated.

That's because the authorization token for a SIP peer is, by definition, the portion within the brackets.  If you want to authenticate with something else, then put something else within the brackets.
By: James Feeney (james nurealm net) 2005-08-19 01:44:33

When the RFC says "A registrar SHOULD authenticate the UAC.", that means what it says.  You can't just blow-off the REGISTER request and still call it Session
Initiation Protocol.

The MANNER of that authentication is _also_ described in the RFC:

22.1 Framework
...
In SIP, a UAS uses the 401 (Unauthorized) response to challenge the identity of
a UAC.
...
22.2 User-to-User Authentication
...
The WWW-Authenticate response-header field MUST be included in 401
(Unauthorized) response messages.
...
...any UA that wishes to
authenticate itself with a UAS or registrar -- usually, but not
necessarily, after receiving a 401 (Unauthorized) response -- MAY do
so by including an Authorization header field with the request.

When Asterisk says 403 Forbidden, it can mean 403 with as much passion as it likes, but it is still NOT AN RFC 3261 COMPLIANT RESPONSE to a REGISTER request.
Asterisk can define the authorization token for a SIP peer as anything it likes,
just don't call it Session Initiation Protocol.  The URI is NOT an Authorization
header.

Asterisk SIP should DO WHAT THE RFC SAYS.  If you have some different
understanding of what the RFC says, then please specify that part of the
RFC dealing with Registration which supports your interpretation.
By: Mark Spencer (markster) 2005-08-19 01:49:55

Quoting RFC out of context isn't going to help you here.  The item you're mentioning says we SHOULD authenticate (as opposed to accepting the request without authentication).  The *very next item* in the list after the one you quote says:

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.

And this is precisely what Asterisk does.  We *do* return 403 because the user does not have the authorization.  No 401, no anything else.
By: James Feeney (james nurealm net) 2005-08-22 10:22:58

Thankyou for articulating your position.  That helps.

After pouring through the RFCs for a few days, I see that I had naively and
erroneously been assuming that the Location Service address-of-record
username was defined by the "Authorization" header username, when in fact,
it is one and the same as the "To" header username according to Section 10.2
"Constructing the REGISTER Request".

Still, I see in Section 8.2.2.1 "To and Request-URI"

  The To header field identifies the original recipient of the request
  designated by the user identified in the From field.  The original
  recipient may or may not be the UAS processing the request, due to
  call forwarding or other proxy operations.

Perhaps you can see why I was so concerned about setting an authname and
being sure to receive an Authorization header.

I could have said "Cart before the horse."  Until the UAC is authenticated,
by following the specific procedure outlined in the RFC, Asterisk has no
basis for determining whether the UAC is authorized or not - no reason, no
justification, no clue, because no REALM has been specified to the UAC in a
"WWW-Authenticate" header, and no Digest Authentication identity information
has been received yet by Asterisk.

With respect to 10.3 "Processing REGISTER Requests":

Step 3
  A registrar SHOULD authenticate the UAC.

Then, Step 4, AFTER Step 3:
   The registrar SHOULD determine if the authenticated user is
   authorized to modify registrations for this address-of-record.

"authenticated" and "authorized" - it's quite an important distinction.
"authenticated" - Step 3, an RFC explicit SIP specification.
"authorized"    - Step 4, an RFC arbitrary administrative policy.

But then I see that Section 8.2.2.1 "To and Request-URI" allows for a policy
decision to CUT SHORT the entire REGISTER request process.

  A UAS MAY apply any policy it wishes to determine whether to accept
  requests when the To header field is not the identity of the UAS.

Though it continues:

  However, it is RECOMMENDED that a UAS accept requests even ... if the To
  header field does not address a known or current user of this UAS.

But what would be the point?  What functionality is lost by NOT going
through the motions?

Those of us who don't like the "403 Forbidden" response specified by the RFC
might prefer instead to see the "404 Not Found" response otherwise specified
by the RFC at 8.2.2.1:

  If, on the other hand, the UAS decides to reject the
  request, it SHOULD generate a response with a 403 (Forbidden) status
  code and pass it to the server transaction for transmission.

  However, the Request-URI identifies the UAS that is to process the
  request.  ... If the Request-URI does not identify an address that the
  UAS is willing to accept requests for, it SHOULD reject the request
  with a 404 (Not Found) response.

There is lots of functionality described in the RFC that could be added to
the Asterisk SIP module - TLS, S/MIME, Third-Party Registration, ...  Hmm, a
project opportunity. ;)  Still, what would be the point?

After some experimentation, it turns out that the issue that got me going -
not being able to set the Station AOR username independently of the Gateway
AOR username - isn't caused by the Asterisk Gateway at all - my mistake -
but is caused by the Sipura Station, an SPA-2100.  That really annoys me.
An Open Source ATA would be nice.

Sipura can not set the REGISTER request Contact header and To header
usernames independently, which is to say that it cannot flexibly set the
Contact Address binding to the Address-Of-Record URI as of firmware version
3.2.1.  Asterisk can, though, no problem.

Asterisk doesn't allow setting the _incoming_ To header and Authorization header
usernames independently.  I'm a little vague about what the consequences are
in the case for Asterisk - No Third-Party Registration?  Does anyone care?

That leaves me with just a "tweak" issue with Asterisk.  I find using the
sip.conf section header to set the AOR username confusing initially.  That
seems to break the style of the configuration file because I normally expect
the section header to be just a label and don't expect the section header to
be a parameter.  It would be less confusing to me if the sip.conf channel
name were an arbitrary label and there were an explicit "AORname" sort of
parameter.  For me, an explicit parameter also highlights the importance and
consequence of the value being set.


The following is completely off point:

       /* Technically you can place arbitrary whitespace both before and
       after the ':' in a header, although RFC3261 clearly says you
       shouldn't before, and place just one afterwards.  If you shouldn't
       do it, what absolute idiot decided it was a good idea to say you can
       do it, and if you can do it, why in the hell would you say you
       shouldn't.  */

I really appreciated that!  It brought a tear to my eye, I was laughing so
hard.  I'd been thinking the same thing myself while reading the RFC.  It's
nice to know other people notice these things.  "Fault Tolerance" would be
the obvious answer, but it still seems ridiculous.
By: Olle Johansson (oej) 2005-08-22 10:34:03

Yes, Asterisk has a local policy that the user name part of the URI has to be the same as the digest auth user name. If we can't find the user, there's no point in authenticating. Also remember that most parts of the auth process is not in RFC3261, but in the RFCs that describe HTTP digest Auth.

Changing this policy is planned for the next version of the SIP channel, but can't easily be done in this version. Believe me, I've tried.
By: Olle Johansson (oej) 2005-08-22 10:35:47

Take discussion to the mailing list, not the bug tracker please.