Eric, thank you for the comments and sorry for the slow response. As you stated this was a first draft solution based on draft-dotson-sip-certificate-auth. We have since updated the requirements draft to -03 which can be found at http://www.ietf.org/internet-drafts/draft-dotson-sip-certificate-auth-03 .txt.
The reasoning behind choosing a challenge/response paradigm is that is the current model used in SIP, and allows a registrar to control when and if to authenticate UAs. S/MIME could be a potential mechanism, as could Identity or AIB in theory. At a high-level we weren't as concerned with the actual mechanism as the signaling and messaging, since the signing of some set of data seems to be similar across all the current solutions. What we seem to be missing is the signaling and messaging to use certificates for authenticating to a registrar/network or another UA. Without challenge/response, the UA would always need to do cryptographic processing and messages are larger, whether or not the other end is requiring authentication. For UA to UA authentication, the issue is even more of a concern, as we don't want UAs assuming authentication of every dialog request. Is it a fair statement that S/MIME/AIB/Identity all use similar cryptographic tools but vary in the specific data from the dialog chosen to sign? Is there any preference to which "mechanism" is used for the solution? Do all the solutions have issues with middleboxes? Thanks. Steve. -----Original Message----- From: EKR [mailto:[EMAIL PROTECTED] Sent: Saturday, March 10, 2007 2:02 PM To: [email protected] Subject: [Sip] Review of draft-dotson-sip-certificate-auth-sol-00 $Id: draft-dotson-sip-certificate-auth-sol-00-rev.txt,v 1.1 2007/03/10 21:13:10 ekr Exp $ The native SIP authentication scheme is Digest authentication. This draft and its companion draft-dotson-sip-certificate-auth argue that it is desirable to have an authentication scheme based on public key certificates that can span multiple hops (TLS client auth lets you authenticate to the first hop proxy). To some extent, SIP already has such a scheme: messages can be S/MIME signed. As I understand it, the primary deficiencies claimed for S/MIME are: - There is no way for the server to indicate he wants you to S/MIME sign. - There is no built-in defense against replay attacks. In order to correct this situation, this draft proposes an extension to HTTP Digest to add a signature mode. I'm not sure how important this problem actually is, but I'm skeptical that this draft is the best way to go about it. It seems to me that this proposal confuses two issues: 1. The formatting of the signature over the data. 2. How the server indicates that it wants a signature. This proposal addresses both, but its solution to (1) is clumsy and replicates functionality we already have, namely S/MIME. It's fine to define a new form of authentication challenge that says "please sign with your S/MIME cert" and even have it include a nonce, but there's no need to model the response on Digest auth. You can simply include the challenge in the material you sign over. Incidentally, I've heard people argue that it would be nice to have a generic solution for both HTTP and SIP. This problem has already been attacked for HTTP (though with minimal adoption). See S-HTTP (RFC 2660). -Ekr _______________________________________________ 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 _______________________________________________ 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
