Subject: [Sipping] sipping-config-framework-06 security

From: Cullen Jennings <[email-masked]>
Date: Fri, 04 Mar 2005 11:17:57 -0800

I really like how most of the security in this is now but there are a few
bits that still need a little tweaking. I don't think I proposing much of a
change to how you imagined it working, just a bit more detail on one of the
cases.

Section 6.1. Small item, in the case of direct connected TLS, the server
still needs to check the identity of the UA. This could be done with
Identity or Digest. You introduce the idea of a device key here. I think you
need to specify what the SubjectAltName of this certificate would look like.
I would say that it MUST have the same name as was used in the user portion
of the URI. This is going to be complicated to describe what the type of it
should be unless this name URN. I can help work on text here.

Section 6.2

At a boxes and arrows level, what is happening is

Client         Server

   --- request----->
   <-- redirect ---
   --- fetch ----->
   <-- result -----

Now the result is going to have confidential information in it, so clearly
we don't want to hand it out to just everyone. This means that the fetch
need to have some credential that only allows the right client to get it.
Saying that this credential is set up from some out of band process is not
realistic - it needs to be provided in the redirect.

Let me consider 3 cases for the credential. #1 is a shared secret that is
directly passed in the fetch, #2 is a shared secret with a digest type
scheme in the fetch, and #3 is some asymmetric key idea. For a protocol like
HTTPS, #1 would work and the URL could be the shared secret. This would
require significant complexity on the web server to make sure these URLs had
limited lifetime and were generate in an way that could not be predicted.
How this was done would need to be discussed. For some other protocols, such
as LDAP, the URL we need a way to provide the user name and password in the
redirect. #2 is similar, HTTP digest could be used but again we needs a way
to provide the user name and password in the redirect. For #3 one might
consider some mutual TLS scheme, but it seems way to complex to figure out
how the server will trust the cert or how client will get the right one to
use so I would rule out this option. I would suggest that we add a way to
include a user name, password, and possibly realm in the redirect result and
go with #1 or #2. If we want to go with HTTPS as the only transport that can
be used here, then we could consider the approach where the URL is the
shared secret. I would drop the current text on mutual TLS - if we don't
want to do this we have to say what the certificate from the client says.
The best place to add this user,password information might be in the
content-indirection-mech draft in the Content-Type header.

I hope this can get some discussion at the upcoming meeting.

Cullen

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP