Subject: [Sip] Interest check: draft on certificate-based authentication

From: Dean Willis <[email-masked]>
Date: Wed, 21 Feb 2007 16:19:23 -0600

The relatively new draft:

http://tools.ietf.org/wg/sip/draft-dotson-sip-certificate-auth- 
sol-00.txt

attempts to resolve the requirements raised in:

http://tools.ietf.org/wg/sip/draft-dotson-sip-certificate-auth-02.txt

As solutions drafts go, this one is substantially incomplete (for  
example, the Security section is basically nonexistent). But I think  
the general approach being taken looks reasonable, and that the  
problem being solved is a real problem that needs to be solved. The  
very real issues with digest authentication are pretty well  
understood, and this sort of technique looks like it will provide a  
very useful alternative.

So I'd like to ask the group to take a look at these drafts and start  
thinking about what we, as a working group, need to do in this area.  
We're perhaps not ready to take on new work at this time, but I  
expect we will be before too much longer. Is this a problem we should  
be addressing?

--
Dean Willis
co-chair

_______________________________________________
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: "Rai, Anupam \(Anupam\)" <[email-masked]>
Date: Thu, 22 Feb 2007 01:11:41 -0700

As of now TLS is the only mechanism available for authentication using
certificate. 
It would be nice to have a solution where certificate can be utilized
for authentication with authentication service more than one hop away
from UA.

-Anupam

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Wednesday, February 21, 2007 2:19 PM
To: SIP IETF
Subject: [Sip] Interest check: draft on certificate-based authentication

--
Dean Willis
co-chair

---

From: "Fries, Steffen" <[email-masked]>
Date: Thu, 22 Feb 2007 10:37:30 +0100

Hi,

the draft addresses certificate based authentication over multiple hops,
were certificate based authentication in TLS does not help. As this may
not only be a problem in SIP scenarios, it would be beneficial to have
such an authentication enhancement within HTTP instead of SIP. As HTTP
digest authentication is currently used in SIP, an enhanced HTTP
authentication utilizing certificates may be used in SIP as well. So
from my point of view the draft sounds interesting, but may have a
broader scope by incorporating it into HTTP directly. The draft already
raises this question in the discussion section.

Ciao
	Steffen

> Sent: Wednesday, February 21, 2007 11:19 PM
> To: SIP IETF

---

From: Matt Lepinski <[email-masked]>
Date: Thu, 22 Feb 2007 10:38:26 -0500

I agree that the approach taken in the document is reasonable and that 
certificate-based authentication over multiple hops is a problem that 
SIP should solve.

However, I disagree with Steffen's suggestion that the work be 
incorporated into HTTP directly. I believe the need for 
certificate-based authentication over multiple hops is a more pressing 
issue for SIP than for HTTP. Therefore, I think we will arrive at a good 
solution sooner if we solve the problem in this working group than if 
first try to solve it first for HTTP and then map the HTTP solution back 
to SIP. (By contrast, in the case of digest authentication, a reasonable 
mechanism already existed within HTTP and therefore it made sense to 
adapt the existing solution to SIP.) If we produce a good multi-hop, 
certificate-based authentication mechanism for SIP and someone believes 
that it is also useful for HTTP, then there's nothing to prevent the SIP 
solution from later being adapted to work with HTTP.

- Matt Lepinski :->

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 23 Feb 2007 17:36:45 -0800

I agree that certificate-based authentication is useful, and have been
working a bit with CableLabs on this specification.

As Matt points out HTTP doesn't involve multiple hops but existing deployed
TLS offloaders do not provide back-end HTTP servers with information about
the TLS session; thus being able to include the certificate authentication
in HTTP itself would allow for usage with HTTP-over-TLS (primarily to
encrypt the transaction) and certificates to provide application-level
authentication (similar to today's use of HTTP's existing Digest and Basic
authentication).

So I support Steffen's idea, but I don't see a suitable APP working group to
standardize this for HTTP.  The immediate need is for SIP.  Perhaps it can
be done in SIP and if there is sufficient interest in the HTTP community
they can adopt a similar (or identical) technique as whatever we create for
SIP?

-d

> From: Matt Lepinski [mailto:[email-masked]] 
> Sent: Thursday, February 22, 2007 7:38 AM
> To: Dean Willis
> Cc: IETF SIP List; [email-masked]
> Subject: Re: [Sip] Interest check: draft on certificate-based 
> authentication
>

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 25 Feb 2007 20:02:54 -0800

I agree that certificate based approach is useful. I am unconvinced  
that there is a situation where it is both

1) you need to have a proxy between the UA that is authenticating and  
the client it is authenticating to

2) there are no other huge security holes introduced by having the  
middle proxy that is not trusted

So - if there is a need for this, then I agree we should look at  
something along these lines. Note that this WG is probably the wrong  
place to design an HTTP authentication scheme that works with  
untrusted intermediaries.

If the intermediaries are not needed, then I think an approach where  
the UA has to do outbound so that the proxy never forms a connection  
to the UA could be used and in this case the UA could present a  
certificate in the TLS handshake that identified the device. Folks  
have been talking about this for several years but waiting for  
outbound to get finished before starting it. Note that this *only*  
works if you know that this certificate will not end up used in a  
normal TLS situation because the certificate will have a device name,  
not a DNS or IP address in it thus the entanglement with outbound.

Cullen <with my individual hat on>

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 27 Feb 2007 19:31:29 -0800

> 1) you need to have a proxy between the UA that is 
> authenticating and the client it is authenticating to
>

This certificate-based scheme isn't different from existing 
state-of-the-art (SIP Digest) in its model of trusting that 
first-hop SIP proxy or having a different proxy perform the 
registration functions.

That is, if your first SIP proxy and your registrar are two
different computers, those same two cases above exist with
SIP Digest.

-d

> > So I support Steffen's idea, but I don't see a suitable APP 
> working  
> > group to
> > standardize this for HTTP.  The immediate need is for SIP.  
> Perhaps  
> > it can