Thanks Elllie! I am currently testing with a bono/sprout built from source (on top of clearwater-upgrade to Bioshock) so I picked up that auth change also. (I'm mainly playing with a file transfer where INVITE is sent with a tel: URI but From is a sip: URI at the moment.)
I can see qop=auth (back from clearwater in REGISTER 401). Now handsets do normal digest authentication using cnonce and nonce-count. The handsets I'm using like that better (one messaging app had some bad behaviour when it did minimal authentication). Looks good to me! :-) James. Auth and WWW-Authenticate fields from and to and from handset(from bono log) now including qop=auth: REGISTER sip:openims.test SIP/2.0 Authorization: Digest username="[email protected]", realm="openims.test", nonce="732c85671fc8fc24", uri="sip:openims.test", response="4101c0b23806a7dc1132a3ebfadc2193", algorithm=MD5, cnonce="1395151710284", opaque="564350b416d8a8e7", qop=auth, nc=00000003,integrity-protected=ip-assoc-yes SIP/2.0 401 Unauthorized WWW-Authenticate: Digest realm="openims.test",nonce="513d1ab8042044d8",opaque="7553b96f69742359",algorithm=MD5,qop="auth" Content-Length: 0 REGISTER sip:openims.test SIP/2.0 Authorization: Digest username="[email protected]", realm="openims.test", nonce="513d1ab8042044d8", uri="sip:openims.test", response="60f0a3e065be1bfa7e11dc113d656d10", algorithm=MD5, cnonce="1395151710284", opaque="7553b96f69742359", qop=auth, nc=00000002,integrity-protected=ip-assoc-yes SIP/2.0 200 OK On 19 March 2014 11:40, Eleanor Merry <[email protected]> wrote: > 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]<[email protected]>] > *On Behalf Of *James Coleman > *Sent:* 14 March 2014 17:37 > *To:* [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]> > > 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 <%2B353894468340> > [email protected] > > AVP: Public-Identity(601) l=42 f=VM- vnd=TGPP > val=sip:+35389x<%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<%2B353894468340> > [email protected] > > AVP: User-Name(1) l=34 f=-M- val=+35389x <%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: Image removed by sender.] > > > > [image: Image removed by > sender.]<http://www.linkedin.com/company/76647?trk=fc_badge> > > > openmindnetworks.com > -- <http://www.linkedin.com/company/76647?trk=fc_badge> openmindnetworks.com
<<inline: image001.jpg>>
_______________________________________________ Clearwater mailing list [email protected] http://lists.projectclearwater.org/listinfo/clearwater
