Nils,
Ok, but the point is that in most of the cases it will be too late already. Maybe an example is helpfull: I try to register via proxy.hotel.com to my registrar at example.com. Note: I'm using the open WLAN of hotel of cours. Now proxy.hotel.com challenges my initial REGISTER request, which my UA replies to with the password which I got at the receiption. Now this second REGISTER request is forwarded to example.com and replied with a 200 OK. When my UA receives the 200 OK it checks the Proxy-Authentication-Info header and detects an error (maybe because a man-in-the-midlle modified something). Upppss! What should the UA do here? Display me a warning "It looks like you successfully registered to example.com. Unfortunately something went wrong. But your credentials where send already to example.com... Maybe now someone else is registered with your account to example.com?!" [S] In the registration example you provide, the SIP UA will need to verify the Authentication-Info header (per RFC 3261), which is specific to the UA-to-registrar interactions. However, the example can be easily generalized for UA-to-Proxy interactions, where the Proxy-Authentication-Info header is used. When the response (say 200 OK) cannot be authenticated, then the UA probably cannot ascertain as to what happened; for example, the proxy could have been an imposter who generated a phony response (i.e., it never reached the intended proxy) or there was a M-i-M who modified a valid response (i.e., it did reach the intended proxy). What the UA can ascertain is that something is wrong! This is similar to the case where it does not receive a response, i.e., the UA does not know if the other end did receive it and the response was lost (in your registration example, the device will be registered without the UA knowing about it), or the other end did not ever receive it (and registration request never made it through). By rejecting an unauthenticated response, the UA can potentially minimize some of the threats (e.g., a hijack of the UA by a phony proxy). Further, actions such as a retry may help. For example, if the proxy sees a retry after it sent a response, then it can ascertain that something went wrong (e.g., the packet was dropped) and clear up associated resources. [Obvious caution: Too many retries can lead to dictionary attacks.] [Of course, if the MiM did not manipulate the parts of the response that are authenticated by the Proxy-Authentication-Info header, then the threat never surfaces. This is a drawback/limitation.] I understand that your draft is only adding the Proxy-Authentication-Info header. On the other hand I doubt that the whole mutual digest auth like it is described in 2617 and 3261 is usuable for SIP at all. [S] Well, digest is being used by quite a few implementations :)! And in the presence of multiple proxies, digest is an option to authenticate (or authorize) end-to-end. Thus, even when TLS is established with the next-hop, it can be a useful tool. Is it a replacement for SIPS? Perhaps not! But what are the other options? > In any case, please refer to the following small thread (3 emails) for > the feedback I received during offline discussions at the last IETF: > > http://www.ietf.org/mail-archive/web/sip/current/msg25882.html >From that small thread I can only ask the same question as Victor did already: what is meant by this trusted connection to the next hop? [S] The feedback I received (as I understood) was that once you establish mutually-authenticated-TLS with the next-hop, you trust any communication over that link (even to registrars and proxies outside of the next-hop). This also meant that the Authentication-Info header (for registration) is redundant (in RFC3261). And another issue in your draft in my opinion is what you describe in second paragraph of section 10: If someone is going to use mutual digest authentication it can not be optional! As recent "demonstrations" on HTTPS and SMTP with TLS have shown security "upgrades" of an IP connection are not optional. If you know that your server (the hotel proxy in the example above) supports mutual auth, you should configure your UA to require mutual auth. If the mutual auth is not there or failed, something is really wrong in the network and you should definately not proceed with whatever you wanted to do. [S] The reason it is optional is primarily due to WG feedback that it may not be required in all cases. For example, if you use SIPS or your access network is always integrity-protected (e.g., Cable access with DOCSIS BPI+). As Section 10 tries to say, use of this header is not a replacement for TLS. It is only useful in architectures where digest is used (with or without TLS) and you prefer mutual authentication to minimize some threats. I say minimize since some threats still exist (e.g., a transparent MiM who is an active or passive participant). - S _______________________________________________ Sip mailing list https://www.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
