>For ACK for non-2xx, you need transport level mechanisms to verify that
>the surce of the ACK is the same as the original request, same with
CANCEL.
By verifying the source, do you mean verifying the previous hop's
address (that is easy to pick) or do you mean verying the
originator's (client's) transport address (with transport layer security)?
If you meant verifying the previous hop's address, what if the previous hop
was a stateless proxy server in a server farm. In this case the ACK gets
forwarded by the stateless proxy. What if the ACK went through a different
stateless proxy in the farm?
What exactly are clients supposed to do when an ACK with bad credentials
is received? Does discarding the ACK mean that we continue retransmitting
the final response? How does this fit in with the bis-05 layer separation?
I presume authentication of messages is performed in the layer above the
transaction layer (if we are not using transport layer security)
and spoofed ACKs without credentials will stop retransmissions of responses
and affect their reliable delivery. With authentication at the transport
layer, the layered approach suggested does not have this problem.
-Binu
Jonathan Rosenberg <[EMAIL PROTECTED]> on 01/15/2002 05:00:11 AM
To: [EMAIL PROTECTED]
cc: Bob Penfield <[EMAIL PROTECTED]>,
[EMAIL PROTECTED], "Peterson, Jon"
<[EMAIL PROTECTED]> (bcc: K Binu/HSSBLR)
Subject: Re: [Sip-implementors] Authentication on ACK
Lorenzo Buoofelli wrote:
> In "draft-ietf-sip-rfc2543bis-05" pag 82 I read:
> "Any time a proxy server or user agent receives a request, they MAY
> challenge
> the initiator of the response to provide assurance of their identity"
>
> Certainly it is valid for Register, Invite, Bye, Cancel and Option.
> Is it valid for ACk too?
>
> Can a proxy require an authentication on a ACK request?
>
No, it can't. Neither for CANCEL. We will fix in bis-06.
[EMAIL PROTECTED] wrote:
> The UA or proxy may demand the client to include the
> (Proxy-)Authorization header field in the ACK, if the client has been
> challenged earlier in the dialog, e.g. for the INVITE request.
For ACK for 2xx, a UAC is supposed to provide the same credentials in it
as the INVITE.
For ACK for non-2xx, you need transport level mechanisms to verify that
the surce of the ACK is the same as the original request, same with CANCEL.
> For
> Digest authentication the client has all information (nonce, nc, qop
> etc.) it need to calculate a correct response value. The problem is that
> if no (Proxy-)Authorization header field is included, what should the UA
> or proxy do if it can't send a response?
Discard.
Thanks,
Jonathan R.
> ----- Original Message -----
> From: Bob Penfield <[EMAIL PROTECTED]>
> Date: Monday, January 7, 2002 2:34 pm
> Subject: Re: [Sip-implementors] Authentication on ACK
>
>
>>There is never a response to an ACK. Therefore a proxy or user
>>agent cannot
>>challenge an ACK. If a challenge was appropriate, it would have
>>occurred for
>>the INVITE.
>>
>>(-:bob
>>
>>Robert F. Penfield
>>Chief Software Architect
>>Acme Packet, Inc.
>>130 New Boston Street
>>Woburn, MA 01801
>>[EMAIL PROTECTED]
>>
>>----- Original Message -----
>>From: <[EMAIL PROTECTED]>
>>To: <[EMAIL PROTECTED]>
>>Sent: Monday, January 07, 2002 1:04 PM
>>Subject: [Sip-implementors] Authentication on ACK
>>
>>
>>
>>>In "draft-ietf-sip-rfc2543bis-05" pag 82 I read:
>>>"Any time a proxy server or user agent receives a request, they MAY
>>>
>>challenge
>>
>>>the initiator of the response to provide assurance of their
>>>
>>identity">
>>
>>>Certainly it is valid for Register, Invite, Bye, Cancel and Option.
>>>Is it valid for ACk too?
>>>
>>>Can a proxy require an authentication on a ACK request?
>>>
>>>Thanks
>>>Lorenzo
>>>
>>>
>>>___________________________________________
>>>
>>>Lorenzo Boffelli
>>>STRE Engineer
>>>
>>>Allied Telesis K.K.
>>>Head Office / 4F TOC Bldg, 7-22-17 Nishi-Gotanda,
>>>Shinagawa-ku, Tokyo Japan, 141-8635
>>>European R&D Center
>>>Piazza Tirana, 24/4 b Phone: +39 02 41411201
>>>20147 Milano Fax: +39 02 41411260
>>>ITALY
>>>Email: [EMAIL PROTECTED]
>>>___________________________________________
>>>_______________________________________________
>>>Sip-implementors mailing list
>>>[EMAIL PROTECTED]
>>>http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>>>
>>>
>>_______________________________________________
>>Sip-implementors mailing list
>>[EMAIL PROTECTED]
>>http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>>
>>
>
> _______________________________________________
> Sip-implementors mailing list
> [EMAIL PROTECTED]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
>
--
Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue
Chief Scientist First Floor
dynamicsoft East Hanover, NJ 07936
[EMAIL PROTECTED] FAX: (973) 952-5050
http://www.jdrosen.net PH: (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
