Subject: RE: [Sip] Certificate authentication in SIP

From: "Steve Dotson" <[email-masked]>
Date: Tue, 3 Jul 2007 15:02:42 -0600

Thanks Vijay, and thanks Scott for the clarification.

The SIP cert auth requirements document currently lists a few use cases:

 - the certificate identifies a device
 - the certificate identifies a user

There could also be the case where the device certificate is mapped to a
user for subscription purposes, and there are probably others.

As Sumanth states, depending on the agreed upon requirements, the
solution could leave these types of specifics as out of scope and just
handle the transport and messaging between UA and registrar, or we could
go so far as to have certificate profiles and requirements and then work
those requirements with the appropriate groups.

Thanks.

Steve. 

-----Original Message-----
From: Scott Lawrence [mailto:[email-masked]] 
Sent: Friday, June 29, 2007 12:32 PM
To: IETF SIP List; [email-masked]
Subject: Re: [Sip] Certificate authentication in SIP

On Fri, 2007-06-29 at 09:37 -0500, Vijay K. Gurbani wrote:
> 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

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.

> Comments on this version would be extremely helpful.

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

_______________________________________________
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: "Steve Dotson" <[email-masked]>
Date: Tue, 3 Jul 2007 15:12:35 -0600

Jon,
 
I don't want to downplay the challenges of certificate management.
However, with TLS gaining traction in different forms, it would seem
these issues are being faced already. There are current PKI deployments
that could leverage existing investments, and certificates are starting
to be used and/or required in different ways in the SIP and mobile
space. Using large IPsec deployments as another example, some operators
are perfectly fine with managing IPsec relationships with shared
secrets, and some see the benefit of certificates. 
 
I honestly don't have much background on the "issues" with S/MIME or
AIB, and we very well may find after discussing the requirements that an
existing solution could be enhanced to meet the requirements. We are
obviously open and encourage re-use.
 
Thanks.
 
Steve.

________________________________

From: Sumanth Channabasappa [mailto:[email-masked]] 
Sent: Friday, June 29, 2007 7:35 AM
To: Peterson, Jon; Dan Wing; Jonathan Rosenberg; DRAGE, Keith (Keith)
Cc: IETF SIP List
Subject: RE: [Sip] Certificate authentication in SIP

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.

> 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'
> Subject: RE: [Sip] Certificate authentication in SIP
>
>
> 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
> > Subject: RE: [Sip] Certificate authentication in SIP
> >
> >
> > 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: Jonathan Rosenberg [mailto:[email-masked]]
> > > Sent: Tuesday, June 26, 2007 3:50 PM
> > > To: DRAGE, Keith (Keith)
> > > Cc: IETF SIP List
> > > 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.
> > >
> > > DRAGE, Keith (Keith) wrote:
> > >
> > > > (As WG chair)
> > > >
> > > >
> > > http://www.ietf.org/internet-drafts/draft-dotson-sip-certifica
> > > te-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
> > > >
> > > >
> > > 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 <http://www.jdrosen.net/>
PHONE:
> (973) 952-5000
> > > http://www.cisco.com <http://www.cisco.com/> 
> > >
> > >

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 3 Jul 2007 14:34:22 -0700

(removed some direct CC's.) 

> From: Steve Dotson [mailto:[email-masked]] 
> Sent: Tuesday, July 03, 2007 2:13 PM
> To: Sumanth Channabasappa; Peterson, Jon; Dan Wing; Jonathan 
> Rosenberg; DRAGE, Keith (Keith)
> Cc: IETF SIP List
> I don't want to downplay the challenges of certificate 
> management. However, with TLS gaining traction in different 
> forms, it would seem these issues are being faced already. 
> There are current PKI deployments that could leverage 
> existing investments, and certificates are starting to be 
> used and/or required in different ways in the SIP and mobile 
> space. Using large IPsec deployments as another example, some 
> operators are perfectly fine with managing IPsec 
> relationships with shared secrets, and some see the benefit 
> of certificates. 
>  
> I honestly don't have much background on the "issues" with 
> S/MIME or AIB, and we very well may find after discussing the 
> requirements that an existing solution could be enhanced to 
> meet the requirements. We are obviously open and encourage re-use.

AIB copies the headers into a separate MIME part and uses S/MIME to sign
that part.  The unfortunate lack of MIME support in SIP is a significant
barrier to the successful deployment of anything using multipart MIME
messages, such as AIB.  From the last SIPit,
http://www.sipforum.org/content/view/287/171/: 

    >
    >    2%  I break if someone sends me multipart/mime
    >   24%  I pretend multipart/mime doesn't exist if someone
    >        sends it to me
    >   24%  I ignore multipart/mime but will proxy it or hand
    >        it to my application if it shows up
    >   10%  I try to do something useful with multipart/mime I
    >        receive, but I never send it
    >    4%  I ignore multipart/mime that I receive, but I try
    >        to do something useful with multipart/mime I send
    >   24%  I try to do something useful with multipart/mime I
    >        send and receive
    >   12%  Other
    >

If you re-used AIB just for Register, the situation may be better, as you
only need the SIP proxy to ignore the multipart portion of the message.

You might also read draft-camarillo-sip-body-handling-01.txt on this topic.

-d

> 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.
> 
> > The certificate authentication would be used in place of 
> today's Digest
> > authentication.
> >