Hi James, A fix for this issue (https://github.com/Metaswitch/homestead/issues/62) has now been released.
If you urgently need this fix, you can pull it from the 'latest' repo, although it hasn't gone through our full end of release QA. Our next stable release that contains this fix will be released in the next few weeks. If you want to use the fix in the 'latest' repo, then you should edit /etc/apt/sources.list.d/clearwater.list/ so that it contains "deb http://repo.cw-ngv.com/~staging/repo binary/", and then run 'sudo clearwater-upgrade' on all of your Clearwater nodes to install the new version. Ellie From: Eleanor Merry Sent: 17 March 2014 18:10 To: 'James Coleman'; [email protected] Subject: RE: [Clearwater] clearwater and open IMS core HSS Digest authentication, no qop in REGISTER 401 Hi James, Thanks for raising this - I agree that the WWW-Authenticate header in the 401 response should contain qop=auth. I've raised an issue to cover this (https://github.com/Metaswitch/homestead/issues/62), and I'm looking into a fix for it. Ellie From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of James Coleman Sent: 14 March 2014 17:37 To: [email protected]<mailto:[email protected]> Subject: [Clearwater] clearwater and open IMS core HSS Digest authentication, no qop in REGISTER 401 Hello, I have looked more into what is happening with SIP Digest authentication on my setup. Authentication is working for me :) but unexpectedly minimal authentication is being done. There is something funny happening with REGISTER on one IMS client I am using and I think it is related to the type of authentication that is being done. I would expect to see qop in SIP REGISTER messages and I am not seeing it. At the start of this year (before Yojimbo) I think REGISTER messages did contain qop=auth. It is not a critical thing but I think it is a bug. ~ thinking maybe about 82% sure on this :-] ~ I think it would be correct to fill in qop value of auth in either homestead (where I think it was before) or in sprout (where I think it is done for AKA type of authentication). I think 3gpp 24.229 on SIP digest populating 401 challenge supports this r"""a "qop" header field parameter; if the qop value is not provided in the authentication vector, it shall contain the value "auth" """ If I look into homestead history in handlers.cpp and cx.cpp I can see . . . There is a recent change (Dec 27) in homestead in this area (Digest handling). I think before if qop was empty it was filled in with "auth". https://github.com/Metaswitch/homestead/commits/dev/src/cx.cpp https://github.com/Metaswitch/homestead/commits/dev/src/handlers.cpp commit d60405265151aec448d593a402f67909adca401c<https://github.com/Metaswitch/homestead/commit/d60405265151aec448d593a402f67909adca401c> Author: Matt Williams <[email protected]<mailto:[email protected]>> Date: Fri Dec 27 17:01:14 2013 +0000 Refactoring and add querying cache for digest -void ImpiAvHandler::on_mar_response(Diameter::Message& rsp) +void ImpiAvHandler::send_reply(const AKAAuthVector& av) - DigestAuthVector digest_auth_vector = maa.digest_auth_vector(); - digest_auth_vector.qop = (!digest_auth_vector.qop.empty()) ? digest_auth_vector.qop : "auth"; - writer.String("qop"); - writer.String(digest_auth_vector.qop.c_str()); + writer.String(JSON_QOP.c_str()); + writer.String(av.qop.c_str()); See in sprout authentication.cpp create_challenge: qop back from homestead is empty string. If qop back from homestead is empty then can auth be filled in instead? I'm thinking that would be the right way to fix this? if (av->isMember("aka")) { // AKA authentication. [chomp] hdr->challenge.digest.qop = STR_AUTH; [chomp] else { // Digest authentication. [chomp] pj_strdup2(tdata->pool, &hdr->challenge.digest.qop, digest["qop"].asCString()); James. I was digging into this trying to understand so some references collected. HSS is not sending Digest-QoP in MAA. I think that is normal. Not sure if it is completely correct behaviour. If I set auth type to be aka in HSS then MAA also doesn't contain Digest-QoP, homestead response to sprout doesn't contain any qop, REGISTER 401 does contain qop=auth (so sprout must have filled it in!) The setup is clearwater IMS core with HSS from open IMS core. Identities in HSS are configured to do SIP Digest authentication. Initial REGISTER comes. REGISTER sent to sprout sprout does http request for impi to homestead homestead does DIAMETER MAR to HSS homestead receives MAA from HSS (MAA doesn't contain Digest-QoP) homestead sends HTTP response to sprout with autrhentication vector with empty qop. sprout sends REGISTER 401 with challenge and without qop subsequent REGISTER comes with response and that is answered 200 OK open IMS core HSS public identities are set up with "SIP Digest" authentication type. REGISTER from phone results in DIAMETER query MAR to HSS MAR from HSS contains SIP-Digest-Authenticate AVP with: Digest-HA1 Digest-Realm MAR to HSS Ack: 1, Len: 404 Diameter Protocol Version: 0x01 Length: 404 Flags: 0xc0 Command Code: 303 Multimedia-Auth ApplicationId: 3GPP Cx (16777216) Hop-by-Hop Identifier: 0x34e32e15 End-to-End Identifier: 0xbdfb5f80 [Answer In: 38] AVP: Session-Id(263) l=65 f=-M- val=xxx;1394719711;372 AVP: Vendor-Specific-Application-Id(260) l=20 f=-M- AVP: Auth-Session-State(277) l=12 f=-M- val=NO_STATE_MAINTAINED (1) AVP: Destination-Realm(283) l=20 f=-M- val=openims.test AVP: Destination-Host(293) l=24 f=-M- val=hss.openims.test AVP: Origin-Host(264) l=50 f=-M- val=xxx AVP: Origin-Realm(296) l=21 f=-M- val=10.124.51.133 AVP: User-Name(1) l=34 f=-M- val=+35389x<tel:%2B353894468340>[email protected] AVP: Public-Identity(601) l=42 f=VM- vnd=TGPP val=sip:+35389x<tel:%2B353894468340>[email protected] AVP: SIP-Auth-Data-Item(612) l=32 f=VM- vnd=TGPP AVP Code: 612 SIP-Auth-Data-Item AVP Flags: 0xc0 AVP Length: 32 AVP Vendor Id: 3GPP (10415) SIP-Auth-Data-Item: 00000260c0000013000028af556e6b6e6f776e00 AVP: SIP-Authentication-Scheme(608) l=19 f=VM- vnd=TGPP val=Unknown AVP: SIP-Number-Auth-Items(607) l=16 f=VM- vnd=TGPP val=1 AVP: Server-Name(602) l=34 f=VM- vnd=TGPP val=sip:xxx<http://10.124.51.133:5054/> MAA from HSS Ack: 405, Len: 408 Diameter Protocol Version: 0x01 Length: 408 Flags: 0x40 Command Code: 303 Multimedia-Auth ApplicationId: 3GPP Cx (16777216) Hop-by-Hop Identifier: 0x34e32e15 End-to-End Identifier: 0xbdfb5f80 [Request In: 37] [Response Time: 0.095592000 seconds] AVP: Session-Id(263) l=65 f=-M- val=xxx;1394719711;372 AVP: Origin-Host(264) l=24 f=-M- val=hss.openims.test AVP: Origin-Realm(296) l=20 f=-M- val=openims.test AVP: Auth-Session-State(277) l=12 f=-M- val=NO_STATE_MAINTAINED (1) AVP: Vendor-Specific-Application-Id(260) l=32 f=-M- AVP: Public-Identity(601) l=42 f=VM- vnd=TGPP val=sip:+35389x<tel:%2B353894468340>[email protected] AVP: User-Name(1) l=34 f=-M- val=+35389x<tel:%2B353894468340>[email protected] AVP: SIP-Number-Auth-Items(607) l=16 f=VM- vnd=TGPP val=1 AVP: SIP-Auth-Data-Item(612) l=124 f=VM- vnd=TGPP AVP Code: 612 SIP-Auth-Data-Item AVP Flags: 0xc0 AVP Length: 124 AVP Vendor Id: 3GPP (10415) SIP-Auth-Data-Item: 00000265c0000010000028af0000000100000260c0000016... AVP: SIP-Item-Number(613) l=16 f=VM- vnd=TGPP val=1 AVP: SIP-Authentication-Scheme(608) l=22 f=VM- vnd=TGPP val=SIP Digest AVP: SIP-Digest-Authenticate AVP(635) l=72 f=VM- vnd=TGPP AVP Code: 635 SIP-Digest-Authenticate AVP AVP Flags: 0xc0 AVP Length: 72 AVP Vendor Id: 3GPP (10415) SIP-Digest-Authenticate AVP: 000000794000002864353037613936313538643631633363... AVP: Digest-HA1(121) l=40 f=-M- val=d507a96158d61c3cae16a9cb9feed75f AVP: Digest-Realm(104) l=20 f=-M- val=openims.test AVP: Result-Code(268) l=12 f=-M- val=DIAMETER_SUCCESS (2001) http://www.3gpp.org/DynaReport/24229.htm 3gpp 24.229 5.4.1.2.1B Challenge with SIP digest as security mechanism On sending a 401 (Unauthorized) response to an unprotected REGISTER request, the S-CSCF shall populate the header fields as follows: 1) a WWW-Authenticate header field as defined in RFC 2617 [21], which transports: - a protection domain in the "realm" header field parameter; - a "nonce" header field parameter (generated by the S-CSCF); - an "algorithm" header field parameter; if the algorithm value is not provided in the authentication vector, it shall have the value "MD5"; and - a "qop" header field parameter; if the qop value is not provided in the authentication vector, it shall contain the value "auth". http://www.ietf.org/rfc/rfc3261.txt RFC 3261 SIP: Session Initiation Protocol June 2002 Use of the "qop" parameter is optional in RFC 2617 for the purposes of backwards compatibility with RFC 2069; since RFC 2543 was based on RFC 2069, the "qop" parameter must unfortunately remain optional for clients and servers to receive. However, servers MUST always send a "qop" parameter in WWW-Authenticate and Proxy-Authenticate header field values. If a client receives a "qop" parameter in a challenge header field, it MUST send the "qop" parameter in any resulting authorization header field. https://www.rfc-editor.org/rfc/rfc4590.txt RFC 4590 RADIUS Digest Authentication 3.8. Digest-Qop Attribute Description This attribute holds the Quality of Protection parameter that influences the HTTP Digest calculation. This attribute MUST only be used in Access-Request and Access-Challenge packets. A RADIUS client SHOULD insert one of the Digest-Qop attributes it has received in a previous Access-Challenge packet. RADIUS servers SHOULD insert at least one Digest-Qop attribute in an Access-Challenge packet. Digest-Qop is optional in order to preserve backward compatibility with a minimal implementation of [RFC2069]. Type 110 for Digest-Qop Length >=3 Text In Access-Requests, the RADIUS client takes the value of the qop directive (qop-value as described in [RFC2617]) from the HTTP-style request it wants to authenticate. In Access-Challenge packets, the RADIUS server puts a desired qop-value into this attribute. If the RADIUS server supports more than one "quality of protection" value, it puts each qop-value into a separate Digest-Qop attribute. http://www.qtc.jp/3GPP/Specs/29229-8a0.pdf 6.3.36 SIP-Digest-Authenticate AVP The SIP-Digest-Authenticate is of type Grouped and it contains a reconstruction of either the SIP WWW-Authenticate or Proxy-Authentication header fields specified in IETF RFC 2617 [14]. AVP format SIP-Digest-Authenticate ::= < AVP Header: 635 10415> { Digest-Realm } [ Digest-Algorithm ] { Digest-QoP } { Digest-HA1} *[ AVP ] 6.3.40 Digest-QoP AVP The Digest-QoP AVP is defined in IETF RFC 4740 [15] https://www.rfc-editor.org/rfc/rfc4740.txt RFC 4740 Diameter SIP Application https://www.rfc-editor.org/rfc/rfc2617.txt RFC 2617 HTTP Authentication qop SHOULD ... [Image removed by sender.] [Image removed by sender.]<http://www.linkedin.com/company/76647?trk=fc_badge> openmindnetworks.com<http://openmindnetworks.com>
<<inline: image001.jpg>>
_______________________________________________ Clearwater mailing list [email protected] http://lists.projectclearwater.org/listinfo/clearwater
