Subject: [Sip] Certificate authentication in SIP

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 13 Jun 2007 17:58:29 +0200

(As WG chair)

http://www.ietf.org/internet-drafts/draft-dotson-sip-certificate-auth-03
.txt 

Describes a set of requirements for:

   This document defines requirements for adding certificate
   authentication to the Session Initiation Protocol (SIP).  This
   document is being presented with the intention of providing clear
   requirements to any potential solutions specifying certificate
   authentication within SIP networks.  Supporting certificate
   authentication in SIP would provide strong authentication and
   increase the types of possible deployment scenarios.

(Before we go any further, please forget all about the solutions
document - that comes later and we are not dealing with it now)

We need to decide whether there is support for a body of work in this
area, and therefore whether we should charter some requirements work in
the SIP WG.

(Because this is security related we have agreed that SIP does the
requirements drafting and not SIPPING)

So can I hear opinions of the WG on:

-	whether this represents a problem space that the working group
should draft requirements on?

-	whether the problem space exists but is something slightly
different, and if so what is that problem space?

-	whether there is a more general problem that the security area
should be addressing, rather than the SIP group addressing something
specific?

-	based on your answers to the first three questions, whether this
draft is essentially in the right direction to be adopted as the WG
draft assuming we create the charter item, or whether we need to seek
some other input draft?

-	and finally, whether (assuming we go ahead with this work) there
is any work in any other IETF WG that we should take account of?

Regards

Keith

Regards

Keith

_______________________________________________
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: "Dan Wing" <[email-masked]>
Date: Tue, 19 Jun 2007 18:39:09 -0700

> should draft requirements on?

Yes; it is desirable and useful to provide an authentication mechanism 
that uses certificates to authenticate a registrar to its UA and a SIP
UA to its registrar, rather than the existing Digest mechanism that
uses a shared secret between the UA and its registrar.

> should be addressing, rather than the SIP group addressing something

I expect you're referring to HTTP, as HTTP is where SIP derived its
Digest authentication from.  

I don't believe HTTP has any need or interest in using certificates
for client authentication; however, as you know, there is some interest
in considering how HTTP's authentication can be 'fixed' (modernized).

> draft assuming we create the charter item, or whether we need to seek

draft-dotson-sip-certificate-auth-03 seems suitable in capturing
requirements.

> is any work in any other IETF WG that we should take account of?

During the discussion of the HTTPbis BoF, 
http://lists.w3.org/Archives/Public/ietf-http-wg
there were some people that suggested RFC2617 (which defines HTTP's
Basic and Digest authentication) also be revised.  This may have some
bearing on SIP, if it is decided that HTTPbis's charter will include
a revision of RFC2617.

-d

---

From: "Fries, Steffen" <[email-masked]>
Date: Wed, 20 Jun 2007 12:44:05 +0200

HI,

> should draft requirements on?
certificate based authentication from my point of view is useful to
increase the security of the 
user authentication, which is currently achieved by HTTP digest.

> should be addressing, rather than the SIP group addressing 
> something specific?
as SIP borrows the digest authentication from HTTP, it might also be
possible to enhance the HTTP authentication and re-use it in SIP for the
certificate based authentication. As Dan already wrote a potential
HTTPbis might capture this approach.

> draft is essentially in the right direction to be adopted as 
> the WG draft assuming we create the charter item, or whether 
> we need to seek some other input draft?
this draft outlines the requirements for certificate based
authentication for SIP and should therefore be used as a requirements
document. I guess it does not necessarily determine, if the solution is
being defined in SIP as opposed to define the base solution for HTTP and
derive a solution in SIP
> is any work in any other IETF WG that we should take account of?
see Dans reference

Regards
	Steffen

> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 21 Jun 2007 10:41:35 -0500

Keith: Please see inline.

> Describes a set of requirements for:
[...]
> should draft requirements on?

I must confess that on an initial reading of the draft, I was
lost on the need for requirements that add certificate
authentication to SIP.  Using TLS, a registrar and a UAC and
exchange certificates today and authenticate each other,
without resorting to a shared secret, right?

I beleive the use case that the author is going for has to do with
using the hop-by-hop signaling path through a SIP proxy mesh to a
registrar, but being able to exchange certificates directly
between the UAC and the registrar.  As such, the title of the
draft ought to be reflective of this; something along the lines
of "Requirements for direct registrar authentication in the
Session Initiation Protocol (SIP) by a User Agent Client (UAC)".

> different, and if so what is that problem space?

If the problem space is defined as coming up with requirements
for direct registrar authentication in SIP by a UAC over a
normal SIP proxy mesh, then that is a reasonable problem space,
IMHO.

> should be addressing, rather than the SIP group addressing something

I beleive that this is fairly specific to SIP, but will defer
to the chairs and the rest of the WG.

> draft assuming we create the charter item, or whether we need to seek

This draft also talks about interpreting the contents of the
certificates (S3, requirement 8).  As such, some of the work Scott
Lawrence and I have done in domain-certs provides more
guidelines on this particular aspect.  We received good feedback
from the pkix WG in Prague when we presented domain-certs
there; we are in the process of revising the domain-certs draft
to include a discrete set of steps that can be programmed to
do certificate validation.  We should be sending a revised
version of this draft out by tomorrow.

> is any work in any other IETF WG that we should take account of?

domain-certs, as mentioned above.  In addition, sip-sipsec could
provide a possible solution set; it appears to fit some of the
requirements.

Thanks.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 21 Jun 2007 18:24:45 -0700

> without resorting to a shared secret, right?

With TLS, the UAC can authenticate its proxy, yes.  But the
establishment of a TLS session, even mutually-authenticated
TLS (which is not mandated by RFC3261, by the way) doesn't 
inheriently provide authentication of the REGISTER message.
I suppose it _could_, but we don't have that written down
anywhere that I'm aware of.

> between the UAC and the registrar. 

Yes, exactly.

-d

> As such, the title of the
> > draft assuming we create the charter item, or whether we 
> > need to seek some other input draft?
>

---

From: <[email-masked]>
Date: Tue, 26 Jun 2007 18:17:29 +0300

Hi,

I think certificate authentication would be a valuable addition to SIP's
arsenal of authentication methods, to better support environments where
certificates can be deployed, in a similar way as RFCs 3310 and 4169
were done to support SIM-based authentication.

So, I would support adding the topic as a charter item and adopting the
requirements draft as a WG item as the starting point.   

Markus

>-----Original Message-----
>From: ext DRAGE, Keith (Keith) [mailto:[email-masked]] 
>Sent: 13 June, 2007 18:58
>To: IETF SIP List
>Subject: [Sip] Certificate authentication in SIP
>
>(As WG chair)
>
>(Before we go any further, please forget all about the 
>solutions document - that comes later and we are not dealing 
>with it now)
>
>We need to decide whether there is support for a body of work 
>in this area, and therefore whether we should charter some 
>requirements work in the SIP WG.
>
>(Because this is security related we have agreed that SIP does 
>the requirements drafting and not SIPPING)
>

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Tue, 26 Jun 2007 10:25:57 -0500

Hello,

Agreed, that this would be a valuable option/alternative to have.

Martin 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, June 26, 2007 11:17 AM
To: [email-masked]; [email-masked]
Subject: RE: [Sip] Certificate authentication in SIP

Hi,

Markus

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 26 Jun 2007 10:35:11 -0500

Same here. 

I think the document needs a bit of work, but it's a good start.

> Sent: Tuesday, June 26, 2007 08:17
> I think certificate authentication would be a valuable 
> addition to SIP's arsenal of authentication methods, to 
> better support environments where certificates can be 
> deployed, in a similar way as RFCs 3310 and 4169 were done to 
> support SIM-based authentication.
> 
> >[email-masked] for questions on current sip Use 
> >[email-masked] for new developments on the application of sip
> >
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Jun 2007 18:58:29 -0400

Hit send too quickly.

An alternate solution here is to just use TLS between the client and its 
next SIP hop. If thats the registrar, great, we're done. If its an 
intermediate proxy - then the intermediate proxy has basically done the 
authentication and can use RFC 4474 or 3325 to convey that authenticated 
identity to the registrar.

If you are worried about cases of local proxies in untrusted networks, 
separate from your home proxy - well there are tons of problems in that 
model and its something we need to discourage.

If you step back a moment - it seems wrong to me that we are going to 
have our clients implement TLS, which supports client authentication 
with certificates, but then tell them that they need to ALSO implement 
something entirely different to accomplish the same thing.

-Jonathan R.

Jonathan Rosenberg wrote:

> Well, I'm going to be contrarian here. I'm not convinced that this is 
> needed.
> 
> I think certificate based authentication is a great idea. However, I am 
> not sure I understand why TLS is not an appropriate solution.
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Jun 2007 18:50:01 -0400

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 26 Jun 2007 19:17:19 -0500

Funny: i was assuming that we were talking about mutual TLS here...

> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Tuesday, June 26, 2007 15:50
> To: DRAGE, Keith (Keith)
> Cc: IETF SIP List
> Subject: Re: [Sip] Certificate authentication in SIP
> 
> Well, I'm going to be contrarian here. I'm not convinced that 
> this is needed.
> 
> I think certificate based authentication is a great idea. 
> However, I am not sure I understand why TLS is not an 
> appropriate solution.
> 
> > area, and therefore whether we should charter some 
> requirements work 
> > in the SIP WG.
> > 
> something

---

From: Dean Willis <[email-masked]>
Date: Tue, 26 Jun 2007 22:32:12 -0500

> not sure I understand why TLS is not an appropriate solution.

I think it is very simple why TLS is not appropriate. TLS doesn't work
across proxies, and would therefore require the edge proxy to do
authentication.
This is why we conventionally use digest or basic auth over TLS.

Certificate authentication would provide the flexibility of TLS + basic
(no challenge/response) with security better than TLS+digest (no replay).

Of course, SIPSEC is another alternative.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 26 Jun 2007 22:36:12 -0500

> model and its something we need to discourage.

I think we're worried about having two authentication domains -- the one
operated by your home proxy (and possibly any "tweeners" like the edge
proxy), and the one operated by a 3rd party from who you acquire
services but that does not necessarily have a business relationship with
and transitive trust of your home proxy. Today, the 3rd party would do
digest auth (or with SIPS, maybe basic), but that has its own set of issues.

--
Dean

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 27 Jun 2007 16:39:32 -0400

I also have to admit I'm a skeptical. Various forms of non-hop-by-hop authentication with certificates were enabled by S/MIME, especially in conjunction with entities like AIBs. As far as I'm concerned, the mechanics have had their day in court, and it didn't go well. We can grapple with the syntax to try to find something slightly different that will actually appeal to the implementation community, but I don't think the problem was that we had the wrong syntax.

Jon Peterson
NeuStar, Inc.

> Sent: Tuesday, June 26, 2007 3:50 PM
> To: DRAGE, Keith (Keith)
> Cc: IETF SIP List
> However, I am

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 27 Jun 2007 16:43:29 -0400

> across proxies, and would therefore require the edge proxy to do

So what? I think thats what ought to happen. I'd like to see some 
specific use cases where this can't work with the edge proxy performing 
the authentication. Keep in mind, we are talking about *certificate* 
authentication; that doesn't (by definition) required any kind of 
pre-arranged secret - only a common root CA.

-Jonathan R.

---

From: Dean Willis <[email-masked]>
Date: Thu, 28 Jun 2007 13:54:56 -0500

On Jun 27, 2007, at 3:39 PM, Peterson, Jon wrote:

>
> I also have to admit I'm a skeptical. Various forms of non-hop-by- 
> hop authentication with certificates were enabled by S/MIME,  
> especially in conjunction with entities like AIBs. As far as I'm  
> concerned, the mechanics have had their day in court, and it didn't  
> go well. We can grapple with the syntax to try to find something  
> slightly different that will actually appeal to the implementation  
> community, but I don't think the problem was that we had the wrong  
> syntax.

I have a hunch that the problem related to the S/MIME and AIB  
dependency.

Anybody ever see an implementation of this stuff in SIP that worked?

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 28 Jun 2007 13:59:54 -0500

On Jun 27, 2007, at 3:43 PM, Jonathan Rosenberg wrote:

>>> this is
> specific use cases where this can't work with the edge proxy  
> performing the authentication. Keep in mind, we are talking about  
> *certificate* authentication; that doesn't (by definition) required  
> any kind of pre-arranged secret - only a common root CA.

My edge proxy might be provided by MCI, but I might be using a chat  
service from another provider overseas. This other provider might be  
willing to trust the certificate for authentication (given that I  
have a signed cert from MCI, who in turn has a signed CA cert from a  
recognized op-level CA). However, the chat provider might not be  
willing to just accept P-Asserted-Identity from MCI as an  
authentication mechanism, since said provider does not have a trusted  
peering arrangement with MCI and therefore ANYBODY could spoof my P- 
Asserted-Identity.

--
Dean

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 29 Jun 2007 01:00:09 -0700

The certificate authentication would be used in place of today's Digest
authentication.

S/MIME and AIB were never used where Digest is used; I don't see the
relationship between what's on the table now and S/MIME and AIB -- except
that they are two certificate-based authentication schemes, S/MIME and AIB
are both intended to work end-to-end (between the two SIP peers desiring to
establish communication with each other), whereas the certificate
authentication being discussed is to replace ("enhance", whatever word you
prefer) the username/password digest authentication.  Digest authentication
isn't done between peers establishing communication with each other (except
in a laboratory environment), but Digest is done to authenticate yourself to
a SIP network so you can gain authorization to interact with that SIP
network --- and that's what's on the table for certificate authentication.

-d

> From: Peterson, Jon [mailto:[email-masked]] 
> Sent: Wednesday, June 27, 2007 1:40 PM
> To: Jonathan Rosenberg; DRAGE, Keith (Keith)
> Cc: IETF SIP List
> I also have to admit I'm a skeptical. Various forms of 
> non-hop-by-hop authentication with certificates were enabled 
> by S/MIME, especially in conjunction with entities like AIBs. 
> As far as I'm concerned, the mechanics have had their day in 
> court, and it didn't go well. We can grapple with the syntax 
> to try to find something slightly different that will 
> actually appeal to the implementation community, but I don't 
> think the problem was that we had the wrong syntax.
> 
> Jon Peterson
> NeuStar, Inc.
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 29 Jun 2007 08:40:42 -0400

I do think that AIB was (and I stress *was*) potentially a tool that could be used in place of Digest, for example, for the registration use case. Nothing about that work limited it to the end-to-end case. Anyway, the new draft does insist that end-to-end is a requirement.

But that's not really material - my note certainly wasn't an attempt to rekindle or in any way glamorize S/MIME or AIB. It was rather a reminder that no small part of the reason why those mechanisms didn't set the world on fire was because of generic certificate enrollment problems, user mobility requiring mobile certificate management, the implausibility of certificates with SIP identifiers as subjects, and a myriad of similar problems that have little to do with whether authentication is end-to-end or what have you - they are rather rooted in the easily-underestimated difficulty of managing the relationship between SIP users, SIP devices, and certificates.

Jon Peterson
NeuStar, Inc.

> From: Dan Wing [mailto:[email-masked]]
> Sent: Friday, June 29, 2007 1:00 AM
> To: Peterson, Jon; 'Jonathan Rosenberg'; 'DRAGE, Keith (Keith)'
> Cc: 'IETF SIP List'

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Fri, 29 Jun 2007 07:34:47 -0600

Jon,

But that's not really material - my note certainly wasn't an attempt to rekindle or in any way glamorize S/MIME or AIB. It was rather a reminder that no small part of the reason why those mechanisms didn't set the world on fire was because of generic certificate enrollment problems, user mobility requiring mobile certificate management, the implausibility of certificates with SIP identifiers as subjects, and a myriad of similar problems that have little to do with whether authentication is end-to-end or what have you - they are rather rooted in the easily-underestimated difficulty of managing the relationship between SIP users, SIP devices, and certificates.
[S] Would this not be part of the reason that we want to tackle this problem? There are large deployments which use certificates successfully today (such as cable clients). There are potential deployments which would like to use certificates for authentication in SIP networks, without a specified explicit way to do this (or perhaps, lack the understanding). Now, certificate management is a valid concern, and potentially a hard problem, but that is only one part of the puzzle (and may not apply to all deployments). 
 
I think we should start by identifying the requirements (since there seems to be some confusion; and the I-D has not been discussed in the WG) and see if existing or new solutions are required. And if we find that certificates need some work to support this initiative (e.g., SIP identifiers as subjects), perhaps we can present some of those requirements to other WGs. If we find an existing solutions that can be used, good (and we can document them as such :) ). 

- s

Jon Peterson
NeuStar, Inc.

> > > http://www.jdrosen.net <http://www.jdrosen.net/>                          PHONE:
> (973) 952-5000
> > > http://www.cisco.com <http://www.cisco.com/> 
> > >
> > >

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 29 Jun 2007 09:37:18 -0500

Sumanth Channabasappa wrote:
> And if we find that certificates need some work to support this
> initiative (e.g., SIP identifiers as subjects), perhaps we can
> present some of those requirements to other WGs. If we find an
> existing solutions that can be used, good (and we can document them
> as such :) ).

Scott Lawrence and I have spent some time on this issue, i.e.,
SIP identifiers as subjects in X.509 certificates.  The latest
version of the draft that includes pkix WG comments from Prague
and the comments of the sip WG ADs and others was posted
last week to the archives, and is available at
http://tools.ietf.org/html/draft-gurbani-sip-domain-certs-05

Comments on this version would be extremely helpful.

Thanks.

- vijay

---

From: Scott Lawrence <[email-masked]>
Date: Fri, 29 Jun 2007 14:32:15 -0400

> http://tools.ietf.org/html/draft-gurbani-sip-domain-certs-05

One qualification - the draft above is limited to certificates as whose
subject is a SIP domain - not an individual.  The goal is to clarify how
such certificates are constructed and constrained, and how they should
be used to authenticate that a server is authoritative for a domain.

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs
  Chief Technology Officer    - Pingtel Corp. http://www.pingtel.com/