Hi, >It would be >helpful to get your feedback on the concept itself, whether you see >challenge/response as the appropriate paradigm, and whether we should >attempt to reuse existing mechanisms such as S/MIME, as there have been >different views on these topics.
I haven't built myself any strong opinion on the usefulness of the ability for the UA/user to authenticate by using certificates issued by a CA or the various mechanism how to do that. In overall it seems that in most of the deployments the SIP devices or users do not have PKI certificates for themselves. So the concept seems to apply only to a few specific deployments only (I do not have any idea how big those deployments could be). What comes to the mechanism, I would tend to agree with Eric's analysis: >>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. These properties suggest using a challenge-response scheme where the server can decide when to challenge and at that moment give a random nonce for the client to use. I think that reusing existing mechanisms (like S/MIME) makes sense in certain respect to decrease the needed specification effort. However the S/MIME approach is also suffers from a few problems: - S/MIME is not widely implemented for SIP, so there is no great reuse expected for existing implementations. Even the basic (multipart) MIME support is lacking from most of the SIP devices and effort has recently been started in SIP WG to specify how those devices should use MIME bodies. Thus I do not believe S/MIME to be an existing and deployed mechanism for SIP which could be easily reused for this purpose. - Tunneling SIP bodies over S/MIME would easily duplicate the size of the message. This does not only take some bandwidth but would typically force the UA to switch its transport to TCP, which again have some issues for deployments based on UDP (as was discussed in a different thread for SIP Outbound). I have not had a look into this, but perhaps it would be worth for you to investigate: >>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). Extending the digest authentication framework with new schemes (like for PKI certificates) is not impossible as proven by RFC 3310 for digest AKA, but getting all details right would require the spec to be written very carefully. Regards, Erkki >-----Original Message----- >From: ext Steve Dotson [mailto:[EMAIL PROTECTED] >Sent: 07.June.2007 19:02 >To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki) >Cc: [EMAIL PROTECTED]; [email protected] >Subject: RE: [Sip] Review of draft-dotson-sip-certificate-auth-sol-00 > >Thanks Erkki for the thorough review. Responses inline... > >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >Sent: Thursday, June 07, 2007 4:47 AM >To: Steve Dotson >Cc: [EMAIL PROTECTED]; [email protected] >Subject: RE: [Sip] Review of draft-dotson-sip-certificate-auth-sol-00 > >Hi Steve, > >I tried to understand how the modified digest algorithm in your draft >works and I have to admit I have difficulties on digesting it. > >First of all your draft tells that the UA should create the >request-digest as follows: > > Once the data string is formed, it MUST be hashed and signed with > private key of the client. The algorithm used for hashing and > signing is specified in the WWW-Authenticate header. > >To verify the received request-digest the server should then do this: > > 6. The server authenticates the client by generating its own > challenge response using the server and client >generated data and > compares its result with that sent in the challenge response by > the client. If the two match, the client has been >authenticated. > >and: > > the server must perform the same cryptographic operation >performed by > the client, and compare the result to the response provided by the > client. > >But how can the server perform the same cryptograpic operation as the >client ? Only the client knows its private key used for creating >request-digest while the server knows only the public key of the user. >The method that you are suggesting would work if there is a shared >secret like in RFC 2617 for HTTP Digest but this is not the case for >using PKI certificates. > >If I have understood it correctly how the digital signatures are used >the process should instead go like this: > >1. The UA creates a hash of the SIP request and the nonce 2. The UA >encrypts the resulting hash with its private key > and sends this digital signature along with the SIP request > >3. The server also creates a hash of the SIP request and the nonce 4. >The server decrypts the encrypted string with the public > key and compares the result to the hash it created in step 3. > >Please tell if you think I have misunderstood any of this. > >[SD] You are correct. This should be clarified. > > >I did not find the draft to describe very clearly how the digital >signing with the private key is performed and which algorithms are used >in different phases of the process. Thus my further questions are >related to the hashing functions introduced in your draft: > > this document, in order to remain consistent with RFC 2617, the > string obtained by applying the algorithm to the data "data" will be > denoted by KD(data)and the string obtained by applying the hash > algorithm to the data "data" will be denoted H(data). > > The algorithm used for hashing and > signing is specified in the WWW-Authenticate header. This document > defines only one "algorithm" value: 'rsa-sha1' > >Does this mean that rsa-sha1 is used for both H(data) and KD(data) ? >If yes, what is then the difference between functions H and KD ? >Or is H(data) supposed to use MD5 instead of rsa-sha1 ? > >Is usage of the private key somehow embedded into your definition of >KD(data) or is signing applied to the hashed string that is received as >a result from KD(data) ? > >[SD] It appears the H(data) is unnecessary, KD could denote the hashing >and encrypting (signing) of the string of data. I was >attempting to work >within the constraints of Digest's current procedures and call flows >while re-using some existing concepts from Identity/AIB/etc. >It would be >helpful to get your feedback on the concept itself, whether you see >challenge/response as the appropriate paradigm, and whether we should >attempt to reuse existing mechanisms such as S/MIME, as there have been >different views on these topics. > >Regards, > >Erkki > >>-----Original Message----- >>From: ext Steve Dotson [mailto:[EMAIL PROTECTED] >>Sent: 05.June.2007 22:13 >>To: EKR; [email protected] >>Subject: RE: [Sip] Review of draft-dotson-sip-certificate-auth-sol-00 >> >>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-certificat >>e-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 >> > > _______________________________________________ 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
