I don’t think that this is the same problem as the upstream bug. The upstream
bug is about checking that the registrar and realm fields are sane. It is
reasonable to question the registrar field, because this identifies a server,
and therefore presumably contains an IP address, host name or domain name.
The SIP RFC, nº 3261, states that “at least one ‘realm’ string supported by a
given server SHOULD correspond to the server’s hostname or domainname.” It
therefore again seems reasonable to question a realm that is not equal to the
registrar, but not reasonable to enforce this, as it is not a requirement of
this RFC or of RFC 2617, HTTP Authentication, on which SIP authentication is
based, and which merely states that “a realm string should include the name of
the host doing the authentication.” A server could have more than one realm,
and RFC 2617 gives the example [EMAIL PROTECTED], which would
be problematic for the suggestion in the upstream bug. On the other hand, I’m
not sure that this is even relevant to Ekiga, as the realm field does not
appear to be accessible with Ekiga’s user interface.
Most of the preceding paragraph doesn’t belong in this bug, except that if I
have understood the upstream bug, my following comments may be useful. If I
have not understood it, then they may or may not be!
So, as suggested in the upstream bug, the reasonable content of the registrar
field (and perhaps the realm field) is governed by the RFCs for IP addresses,
host names and domain names. However, I don’t believe that this has any
relevance to other fields. In particular, I don’t think that it is relevant
to passwords, which are never sent in the clear during SIP authentication. It
is possible, though inadvisable, to include a password in a SIP URI, but even
then all characters are allowed, so long as they are suitably escaped.
Therefore, I am removing the link between this bug and the upstream bug.
In any case, I can reproduce the problem that is described in this bug, but I
don’t think that it is a bug in Ekiga, the client.
I can successfully register with my own SIP (Asterisk) server using Ekiga with
a password containing an “ñ”.
I have logged the network traffic as registrations are attempted, both with my
server and with Ekiga.net, and have verified that Ekiga’s authentication
responses are correct for both servers, both with and without an “ñ”.
I suspect that the bug is in Ekiga.net’s server. It could be that some router
along the way is altering the Authentication header, but I hope that no-one
would do this! (Then again, our home router rewrites SIP Call-ID headers, and
other things that it shouldn’t, so you never know.) The SIP User Agent Server
that responds at ekiga.net is SIP Express Router, so just maybe the bug is in
this or whichever method Ekiga.net is using to store user details behind it.
I used Wireshark to log Ekiga’s communications, and wrote a script to
calculate the authentication response that Ekiga should create, which in each
case matches up with what it does create. (Admittedly, I tweaked my script
till its output matched Ekiga’s, so this may have been self-fulfilling, but I
wrote it based on RFC 2617, and have since cleaned it, checked its algorithm
against the RFC, and rewritten it in another language, so unless there is a
large piece of ambiguity in the RFC, I think the script is probably correct.)
Wherever the problem actually lies, it may well be caused by character
encoding (of course!). RFC 3261 clearly states that SIP uses UTF-8. However,
as passwords are never sent in the clear within the protocol, it could be that
some people deal with passwords in a different encoding (or not properly at
all!), which would lead to differences when hashes are calculated. (In fact,
according to RFC 2617, a server should not store passwords in the clear, but
should store the hashed username:realm:password value.)
I could provide my script if that would help (although it is very badly
written!). Alternatively, someone could temporarily change their password in
Ekiga, and paste the Authorization header that it creates, so that it can be
checked.
A couple of details:
* My Asterisk server is the same host that Ekiga is running on. However,
the connection is made through several DNS resolutions and a router, so
I don’t think that this is relevant.
* Ekiga.net, presumably because it is running SER, uses a slightly
different authentication routine from my server (it includes a qop
directive, and therefore the response includes a client-chosen “cnonce”
value). Therefore, it could be that Asterisk, my script and Ekiga all
get the simpler algorithm correct, but both my script and Ekiga make the
same mistake when calculating the (slightly) more complicated response,
and Ekiga.net checks this incorrect response against the correct value.
I am marking this bug as Invalid because, based on the information so far, the
problem does not appear (to me, at least) to be in Ekiga, the client. It
would of course be worth trying to replicate this problem with other SIP
providers and server software. I may install SER and try authenticating with
it. Perhaps Ekiga.net is already aware of an issue. If the root of this
problem cannot be tracked down elsewhere, then perhaps this bug should be
reopened as Incomplete, so that Ekiga, the client, can be investigated
further.
** Changed in: ekiga
Importance: Unknown => Undecided
Bugwatch: GNOME Bug Tracker #350160 => None
** Changed in: ekiga
Status: New => Invalid
** Changed in: ekiga (Ubuntu)
Assignee: Ubuntu Desktop Bugs (desktop-bugs) => (unassigned)
Status: Triaged => Invalid
--
Ekiga - "Registration failed: Forbidden" with an 'ñ' in the pwd
https://bugs.launchpad.net/bugs/242798
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
