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
