< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] qop Parameter Parsing


The BNF in the RFC specifies that the qop in Proxy-Authorization and Authorization header-field-values is unquoted. People have thrown around the idea of having resip allow the quoted version, but it appears that this hasn't yet been done. Should we just go ahead and do this for interop's sake?

Best regards,
Byron Campen

Hi,

 

I just came across a serious issue where clients are unable to authenticate if they send the qop Parameter in a Proxy-Authorization in quotes. Eg it sends ……,qop=”auth” instead of …..,qop=auth

 

The code in qopparameter.cxx will classify this as qopOptions parameter as you can see from the following code:

 

 

   if (*pb.position() == Symbols::DOUBLE_QUOTE[0])

   {

      pb.reset(anchor);

      return new QuotedDataParameter(ParameterTypes::qopOptions, pb, terminators);

   }

   else

   {

      pb.reset(anchor);

      return new DataParameter(ParameterTypes::qop, pb, terminators);

   }

 

As far as I can see from the RFC it doesn’t say that the qop parameter in a proxy-authorization must not be quoted, so I seems that the assumtion this code is making is incorrect. (Even if it was right, there are clients that send the qop param quoted…)

 

But how to fix it? What would be the correct criteria to determine which type of parameter it actually is? Why is there a qopOptions and a qop Parameter at all?

 

 

Best regards,

 

Matthias Moetje

<image001.jpg>

TERASENS GmbH
Augustenstraße 24
80333 Munich
GERMANY

 

Phone:
Fax:
e-mail:
Web:

+49.89.143370-0
+49.89.143370-22
info@xxxxxxxxxxxx
www.terasens.com

 

 

<image001.jpg>
_______________________________________________
resiprocate-devel mailing list

Attachment: smime.p7s
Description: S/MIME cryptographic signature