[reSIProcate] auth info in BYE same as INVITE 403 /advancedAuthenticateRequest() passes millsecond expires, but compares seconds

[Justin Matthews]

Thanks Scott.

 

The problem here is that calls will not be torn down because the UA will not
retry the BYE when receiving a 403.  This is also true if an app requires
authentication on BYE's and the UA incorrectly sets any of the auth
information in the BYE which will results in a 403.  Thinking of it that
way, this is just how the authentication mechanism works and is a side
effect of incorrect UA behavior.  

 

Some final thoughts for the record on this for my app: To handle this
behavior I can handle onAuthFailure and check the request method, if its BYE
then I can simply send a BYE request.  I could do another MD5 hash using
method "BYE" instead of INVITE (in onAuthFailure), at least this way I would
know that the credentials are valid, still poor behavior though.

 

Thanks,

 

-Justin

 

  _____  

From: Scott Godin [mailto:slgodin at icescape.com] 
Sent: Monday, March 05, 2007 10:32 AM
To: Justin Matthews; resiprocate-devel at list.resiprocate.org
Subject: RE: [reSIProcate] auth info in BYE same as INVITE 403
/advancedAuthenticateRequest() passes millsecond expires,but compares
seconds

 

I suspect a value of 3000 seconds (50 minutes) was intentional since 3
seconds doesn't seem reasonable - although I can't answer why 50 minutes was
chosen.  

 

Also - I think your first question is interesting, but I don't know the
answer.  : )

 

Scott

 

From: resiprocate-devel-bounces at list.resiprocate.org
[mailto:resiprocate-devel-bounces at list.resiprocate.org] On Behalf Of Justin
Matthews
Sent: Saturday, March 03, 2007 8:08 PM
To: resiprocate-devel at list.resiprocate.org
Subject: [reSIProcate] auth info in BYE same as INVITE 403
/advancedAuthenticateRequest() passes millsecond expires,but compares
seconds

 

If DUM challenges an INVITE and then successfully authenticates a call and
the UA then sends DUM a BYE and copies the auth info from the original
INVITE, a 403 is returned because the Method portion of the request-uri is
used in calculating A2 and the Method is now BYE and originally was INVITE.

 

Is this behavior by the UA sending the BYE completely against the spec(s),
or should DUM be able to allow my app to decide whether to accept this kind
of behavior?

 

Also, the call to advancedAuthenticateRequest in ServerAuthManager.cxx
passes 3000 as a hard-coded expiration for the nonce value, is this meant to
be 3 seconds?  The comparison on nonce expiration values is done in seconds
in advancedAuthenticateRequest.  On a side note, how was the value of the
expiration interval decided?

 

Thanks,

 

Justin

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070305/813da7af/attachment.htm>