hi,
I'm trying to use www_authorize/www_challenge (ser 0.8.11/solaris) together with my cisco 7960 (auth backend is mysql and calculate_ha1=1).
when I reach www_authorize (with, as I believe, proper authorization) I get the following error message:
pre_auth(): Credentials received are not filled properly
sent to client: WWW-Authenticate: Digest realm="zettou.net", nonce="3f5e52fd5db948e3b493525f89fe24bfd0f86d9e", qop="auth"
sent from client: Authorization: Digest username="jakob@schlyter.net", realm="zettou.net",uri="sip:schlyter.net", response="8503ab9b93e73ef0033d0e265f31dd0f", nonce="3f5e52fd5db948e3b493525f89fe24bfd0f86d9e", cnonce="718436df",qop=auth,nc=00000001,algorithm=md5
what have I done wrong?
jakob
Hello,
domain in username attribute must be same as the value of realm attribute.
Jan.
On 10-09 00:30, Jakob Schlyter wrote:
hi,
I'm trying to use www_authorize/www_challenge (ser 0.8.11/solaris) together with my cisco 7960 (auth backend is mysql and calculate_ha1=1).
when I reach www_authorize (with, as I believe, proper authorization) I get the following error message:
pre_auth(): Credentials received are not filled properly
sent to client: WWW-Authenticate: Digest realm="zettou.net", nonce="3f5e52fd5db948e3b493525f89fe24bfd0f86d9e", qop="auth"
sent from client: Authorization: Digest username="jakob@schlyter.net", realm="zettou.net",uri="sip:schlyter.net", response="8503ab9b93e73ef0033d0e265f31dd0f", nonce="3f5e52fd5db948e3b493525f89fe24bfd0f86d9e", cnonce="718436df",qop=auth,nc=00000001,algorithm=md5
what have I done wrong?
jakob
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
On Wed, 10 Sep 2003, Jan Janak wrote:
domain in username attribute must be same as the value of realm attribute.
because of the implementation in ser? I understand this is not the case for digest authentication in general, no? According to RFC2617, the realm doesn' even have to be a domain.
anyway, after changing the realm to "" I get the data below. it seems to me that the internal calculate_ha1 (I use calculate_ha1=1) gets the wrong hash?
WWW-Authenticate: Digest realm="schlyter.net", nonce="3f5ebb4f2b39fb9cddbaf991430cebc22b0c3d30", qop="auth"
Authorization: Digest username="jakob@schlyter.net",realm="schlyter.net", uri="sip:schlyter.net",response="3d38e621a815df0c2589656c294b9129", nonce="3f5ebb4f2b39fb9cddbaf991430cebc22b0c3d30",cnonce="77390415", qop=auth,nc=00000001,algorithm=m
0(27788) HA1 string calculated: 5e860120544c1454fee11f18b334e4ed 0(27788) check_response(): Our result = '2544fd772b025e8ce54da191166ea319'
however,
itodenwa> ./gen_ha1 jakob schlyter.net ser2003 5e860120544c1454fee11f18b334e4ed
if I run this again, "check_response(): Our result" gives me another value for the hash - I guess this should stay the same?
jakob
On Sep 10, 2003 at 07:50, Jakob Schlyter jakob@rfc.se wrote:
On Wed, 10 Sep 2003, Jan Janak wrote:
domain in username attribute must be same as the value of realm attribute.
because of the implementation in ser? I understand this is not the case for digest authentication in general, no? According to RFC2617, the realm doesn' even have to be a domain.
anyway, after changing the realm to "" I get the data below. it seems to me that the internal calculate_ha1 (I use calculate_ha1=1) gets the wrong hash?
WWW-Authenticate: Digest realm="schlyter.net", nonce="3f5ebb4f2b39fb9cddbaf991430cebc22b0c3d30", qop="auth"
Authorization: Digest username="jakob@schlyter.net",realm="schlyter.net", uri="sip:schlyter.net",response="3d38e621a815df0c2589656c294b9129", nonce="3f5ebb4f2b39fb9cddbaf991430cebc22b0c3d30",cnonce="77390415", qop=auth,nc=00000001,algorithm=m
0(27788) HA1 string calculated: 5e860120544c1454fee11f18b334e4ed
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
0(27788) check_response(): Our result = '2544fd772b025e8ce54da191166ea319'
however,
itodenwa> ./gen_ha1 jakob schlyter.net ser2003 5e860120544c1454fee11f18b334e4ed
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
calculate_ha1 gets the correct hash.
if I run this again, "check_response(): Our result" gives me another value for the hash - I guess this should stay the same?
No, it should stay the same only if you have the same nonce, nc, cnonce, qop, request method and digest uri value.
check_response returns (when qop is present): MD5 ( ha1 ":" unq(nonce-value) ":" nc-value ":" unq(cnonce-value) ":" unq(qop-value) ":" ha2 )
ha2 = MD5(method ":" digest-uri-value) (in this case)
Andrei
On 10-09 07:50, Jakob Schlyter wrote:
On Wed, 10 Sep 2003, Jan Janak wrote:
domain in username attribute must be same as the value of realm attribute.
because of the implementation in ser? I understand this is not the case for digest authentication in general, no? According to RFC2617, the realm doesn' even have to be a domain.
Yes, this is our policy. The realm is only a string, nothing more. Since a message can contain several digest credentials headers, the realm is used to distinguish among them. So, you configure your proxy to use one particular realm and it then tries to find credentials with that realm and ignores any other.
anyway, after changing the realm to "" I get the data below. it seems to me that the internal calculate_ha1 (I use calculate_ha1=1) gets the wrong hash?
If you use www_challenge("") and www_authorize("") then the server extracts the realm from the message. If it is REGISTER then the From domain will be used, otherwise the To domain will be used.
WWW-Authenticate: Digest realm="schlyter.net", nonce="3f5ebb4f2b39fb9cddbaf991430cebc22b0c3d30", qop="auth"
This is the challenge that will be sent to the user.
Authorization: Digest username="jakob@schlyter.net",realm="schlyter.net", uri="sip:schlyter.net",response="3d38e621a815df0c2589656c294b9129", nonce="3f5ebb4f2b39fb9cddbaf991430cebc22b0c3d30",cnonce="77390415", qop=auth,nc=00000001,algorithm=m
0(27788) HA1 string calculated: 5e860120544c1454fee11f18b334e4ed 0(27788) check_response(): Our result = '2544fd772b025e8ce54da191166ea319'
however,
itodenwa> ./gen_ha1 jakob schlyter.net ser2003 5e860120544c1454fee11f18b334e4ed
You must use ./gen_ha1 jakob@schlyter.net schlyter.net ser2003 to get the same hash.
The reason is that you have realm in the username. A user agent that sent the credentials above also calculate the response using "jakob@schlyter.net" as username so you must do the same.
BTW you don't have to put @chlyter.net into the username, it is not mandatory, you can use just "jakob".
The reason why do we handle this special case (realm in username) is that there are some user agents which put this into username automatically and it can't be switched off. Also, realm parameter in the credentials is not protected by the hash so from time to time people prefer to include the realm into the username parameter which is protected by the hash.
Jan.
One more thing, ./gen_ha1 generates HA1 string (see rfc2617), this is not the response, but the response is calculated from it.
Jan.
On 10-09 13:53, Jan Janak wrote:
itodenwa> ./gen_ha1 jakob schlyter.net ser2003 5e860120544c1454fee11f18b334e4ed
You must use ./gen_ha1 jakob@schlyter.net schlyter.net ser2003 to get the same hash.
The reason is that you have realm in the username. A user agent that sent the credentials above also calculate the response using "jakob@schlyter.net" as username so you must do the same.
BTW you don't have to put @chlyter.net into the username, it is not mandatory, you can use just "jakob".
The reason why do we handle this special case (realm in username) is that there are some user agents which put this into username automatically and it can't be switched off. Also, realm parameter in the credentials is not protected by the hash so from time to time people prefer to include the realm into the username parameter which is protected by the hash.
Jan.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
On Wed, 10 Sep 2003, Jan Janak wrote:
You must use ./gen_ha1 jakob@schlyter.net schlyter.net ser2003 to get the same hash.
does the internal ha1 calcualtion tries to match both username@domain and only username? it seems to me it only tries to match the hash for username.
The reason is that you have realm in the username. A user agent that sent the credentials above also calculate the response using "jakob@schlyter.net" as username so you must do the same.
I though ser was doing the hashing since i set calculate_ha1=1.
BTW you don't have to put @chlyter.net into the username, it is not mandatory, you can use just "jakob".
how could it separate jakob@schlyter.se and (some other) jakob@example.com user if I don't put the domain in the username?
jakob
On 10-09 16:53, Jakob Schlyter wrote:
On Wed, 10 Sep 2003, Jan Janak wrote:
You must use ./gen_ha1 jakob@schlyter.net schlyter.net ser2003 to get the same hash.
does the internal ha1 calcualtion tries to match both username@domain and only username? it seems to me it only tries to match the hash for username.
There was a bug in the digest code (discovered by Andrei), if you use calc_ha1 and "jakob@schlyter.net" in the digest username then the server will not authenticate you.
You have two choices, either update the server from the stable branch of the CVS where the problem is fixed or use only "jakob" in the digest username.
The reason is that you have realm in the username. A user agent that sent the credentials above also calculate the response using "jakob@schlyter.net" as username so you must do the same.
I though ser was doing the hashing since i set calculate_ha1=1.
Yes, but if you have calculate_ha1=1 then you don't need gen_ha1. I thought you wanted to generate HA1 strings and insert them into the database.
BTW you don't have to put @chlyter.net into the username, it is not mandatory, you can use just "jakob".
how could it separate jakob@schlyter.se and (some other) jakob@example.com user if I don't put the domain in the username?
Separate ? If you enter username and password in your user agent then it should display the realm to you so you know for which realm are the credentials used.
Example:
Please enter username and password for realm "iptel.org": Username: Password:
It is the server who chooses the realm/domain. User agents can't change it.
What exactly are you trying to achieve ?
Jan.
-
Andrei Pelinescu-Onciul -
Jakob Schlyter -
Jan Janak