Trying to drill down to the mechanics of how this will work so the
draft can be updated...
Hadriel Kaplan wrote:
No, B does have a way of verifying it's talking to A. B can digest
challenge A for the requests it got from A over that same connection
previously.
What if A and B are proxies? Digest will not work in that case.
As written in the draft, B has no way to verify it's
talking to A when it creates a new TCP connection to A, other than to
believe the TCP listener is A and SYN/ACK exchange is happening with
A.
Well, insofar if you trust DNS (yes, I know the fallacy of that
assumption, but ...), B has some semblance that it is talking to A
since it got A's routing address from a DNS query.
But we don't have to say anything about this. Just remove the
MUST statement in the draft that A must not accept requests from B
over a TCP or single-sided TLS connection created by A to B. You
already say B must not reuse the connection to A because it's not
authenticated. Leave it at that.
Remove the statement, or soften the normative tone to a SHOULD?
I am not arguing this just for the sake of argument. Today this
property of reusing the connection from A to B for requests back to A
is already deployed, and is essential for NAT traversal to work. It
works, and is as secure as could be under the circumstances. A
creates a TCP or client-TLS connection to B. A sends a request, B
challenges it, A answers the challenge. B can then knowingly send
requests over the connection to A, and there's no reason for A to
reject them.
Problem is that this challenge-response mode in SIP is defined
in HTTP Digest, and that is applicable only between a proxy/registrar
and a UA. What happens if A and B are proxies? Or am I missing
something?
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: [EMAIL PROTECTED],bell-labs.com,acm.org}
WWW: http://www.alcatel-lucent.com/bell-labs
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
