Subject: RE: [Sip] Review of draft-dotson-sip-certificate-auth-sol-00

From: "Steve Dotson" <[email-masked]>
Date: Tue, 5 Jun 2007 13:13:28 -0600

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-masked]] 
Sent: Saturday, March 10, 2007 2:02 PM
To: [email-masked]
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-masked] for questions on current sip Use
[email-masked] 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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: <[email-masked]>
Date: Thu, 7 Jun 2007 13:46:46 +0300

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.

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) ?

Regards,

Erkki

>From: ext Steve Dotson [mailto:[email-masked]] 
>Sent: 05.June.2007 22:13
>To: EKR; [email-masked]
>Subject: RE: [Sip] Review of draft-dotson-sip-certificate-auth-sol-00
>

---

From: "Steve Dotson" <[email-masked]>
Date: Thu, 7 Jun 2007 10:02:02 -0600

Thanks Erkki for the thorough review. Responses inline... 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, June 07, 2007 4:47 AM
To: Steve Dotson
Cc: [email-masked]; [email-masked]
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:

To verify the received request-digest the server should then do this:

and:

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.

[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:

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

>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

>cryptographic tools but vary in the specific data from the dialog 
>chosen to sign?
>

---

From: <[email-masked]>
Date: Fri, 8 Jun 2007 08:57:07 +0300

Hi, 

>It would be

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

>>- 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

>>attacked for HTTP (though with minimal adoption). See S-HTTP (RFC 

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

>Sent: 07.June.2007 19:02
>To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki)

---

From: <[email-masked]>
Date: Fri, 8 Jun 2007 09:09:50 +0300

Hi Steve,

One more thing for you to think just in case you 
will continue with your effort of extending the
digest framework for this:

>and encrypting (signing) of the string of data.

I believe that you have to separate the steps of (a) hashing

>   key and compares the result to the hash it created in step 3.

Thus you probably need to define two functions:

a) One for creating the hash from the SIP request. This 
   function does not use any secret or public key. Most
   probably the parts of the request to be hashed are as
   specified in AIB RFC 3893.

b) Another for creating the digital signature over the hash.
   This function takes as its input the hash from the previous
   step and the private key related to user's certificate.

These two functions could use different hash functions,
so you have to specify both.

P.S. Please do not believe me to be an experienced
security expert, I am just in process of learning
cryptography by myself.

Regards,

Erkki