Yes, this is a very plausible case.
Paul
Sanjay Sinha (sanjsinh) wrote:
> Isn't there another case where in-dialog request may be authenticated:
> Sender of the request was authenticated during initial dialog setup and
> the next in-dialog request has the Authorization header, but the nonce
> has expired at the authenticating server/proxy and so it generates
> another nonce and issues a challenge to the sender of that request?
>
>
> Sanjay
>
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On
>> Behalf Of Paul Kyzivat (pkyzivat)
>> Sent: Monday, January 28, 2008 9:11 AM
>> To: Steve Langstaff
>> Cc: SCG2; sip-implementors@lists.cs.columbia.edu
>> Subject: Re: [Sip-implementors] Challenging a sendonly INVITE
>>
>> The question is a little too narrow. The same issues apply to
>> any in-dialog request.
>>
>> Steve makes a good point. But practically speaking
>> authentication is rarely done on in-dialog requests. Bypassing
>> it assumes that the dialog id is only known to the parties on
>> the signaling path, even though this might not be true.
>>
>> In most cases, in the original scenario here Phone A would not
>> share a secret with Phone B that could be used for
>> authentication. So if Phone A
>> issues a challenge there is a strong likelihood that it will fail.
>> This wouldn't necessarily cause the call to fail, but wouldn't help.
>> BUT, if Phone A *does* issue a challenge like this, then of
>> course Phone B should properly respond to it if it has the
>> proper credentials to do so.
>>
>> Paul
>>
>> Steve Langstaff wrote:
>>> How do you know it *really* is phone B that is asking for the HOLD?
>>>
>>>> From: [EMAIL PROTECTED]
>>>> [mailto:[EMAIL PROTECTED] On
>> Behalf Of
>>>> SCG2
>>>>
>>>> Is there any circumstance at all where it makes sense to
>> challenge an
>>>> INVITE which is putting a call on hold?
>>>>
>>>> I can find nothing in 3264 that suggests it, but wondered if:
>>>>
>>>> Phone A -> Phone B (in doing so phone A may have been authenticated)
>>>>
>>>> Phone B later goes to put phone A on hold
>>> _______________________________________________
>>> Sip-implementors mailing list
>>> Sip-implementors@lists.cs.columbia.edu
>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>
>> _______________________________________________
>> Sip-implementors mailing list
>> Sip-implementors@lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
