Hi Sumanth, > In the case you describe, the UAC cannot trust the response. So it can > take actions similar to when it does not receive a valid response: e.g., > it can reasonably retry, log the error, and/or any other appropriate > behavior specified by the architecture.
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?!" > RFC3261 supports the Authentication-Info header (used in registration) > and not the Proxy-Authentication-Info header; which is why this I-D was > authored in the first place. The reference was to ensure that the > behavior is kept consistent, and available irrespective of registration > and non-registration messages. 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. > 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? 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. If you insist on the Proxy-Authorization-Info header being optional is will be of no use at all. Because in all positiv working scenario it will be present and working. But in all scenarios with broken, tapped or whatever networks the header will be missing and your UA should send any message with credentials in first place. Best regards Nils Ohlmeier > > - S > > -----Original Message----- > From: Nils Ohlmeier [mailto:[email protected]] > Sent: Thursday, March 12, 2009 12:50 PM > To: [email protected] > Cc: [email protected]; Stuart Hoggan; Sumanth Channabasappa > Subject: Question regarding draft-dotson-sip-mutual-auth-03 > > Hello, > > after reading the mutual auth draft: > > http://tools.ietf.org/id/draft-dotson-sip-mutual-auth-03.txt > > I have an open question: > what should the client do if the server send authentication informations > in a Proxy-Authentication-Info header back in a let say 200 response, > but > when the client computes response it comes to a different result (e.g. > because man in the middle changed something in the messages)? > > In chapter 5 of your draft you are simply referring to RFC3261 for more > details regarding the implementation of the UAC. But I failed to find > any > information about the UAC handling of this header in 3261. Even RFC2617 > gives no hints, at least I did not found any, what a client should do > when > the server authentication fails. > So it is probably not your fault, but still an interesting question I > think. Especially because the client has already send its credentials > when > the check of the server authentication fails. > > Best regards > Nils Ohlmeier > > _______________________________________________ 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
