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

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


Yes, this is correct.  UA1 is copying the auth info from the successful
initial auth negotiation for the INVITE.

How does DUM determine that the A2 value is wrong and not the credentials
(A1)?  In this case the entire hash could be re-computed by replacing the
method parameter in A2 with INVITE and re-comparing the response="..." in
the auth header.  I'm probably missing something here, because this method
does not seem like a reasonable overall solution.

Thanks,

-justin

-----Original Message-----
From: jason.fischl@xxxxxxxxx [mailto:jason.fischl@xxxxxxxxx] On Behalf Of
Jason Fischl
Sent: Monday, March 05, 2007 11:24 AM
To: Justin Matthews
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] auth info in BYE same as INVITE 403 /
advancedAuthenticateRequest() passes millsecond expires, but compares
seconds

On 3/3/07, Justin Matthews <jmatthewsr@xxxxxxxxx> wrote:
> 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.
>
Can you clarify which user agent you are talking about in this case?

T1: UA1  sends INVITE to UA2 (dum)
T2: UA2 challenges with 407
T3: UA1 resend INVITE to UA2 with credentials
...
T4: UA1 sends BYE to UA2 (dum) copying credentials from INVITE
T5: UA2 sends 403

Is this the behavior you are seeing? In this case UA2 should send a
407 in T5 if the method is used to compute the nonce in T2.

Jason


>
>
> 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
>
>
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>