Subject: [Sip] Comments on sip-response-identity

From: "Derek MacDonald" <[email-masked]>
Date: Tue, 21 Mar 2006 08:02:19 -0800

Hi Feng, 

There are some interesting approaches in this draft. The main issue still
seems to be how a proxy(response identity service) trusts a response enough
to sign it. A few specific comments:

* for DAS how does a proxy trust a given response enough to sign it? One
straw-man approach is:

 To use DAS, a UAS must register over a secure channel.  The proxy

 will authenticate the user using digest challenge and a shared secret.

 For TLS, only one identity will be allowed per TLS session.  Only when

 these requirments are met can a proxy provide responder identity using

 DAS.  This is similar to how a proxy can claim SIPS for an aor even if

 the UA in question does not have a certificate.  

One consequence of this approach is that a secure channel to the registrar
is required, and the same issues as discussed in draft-ietf-sip-identity
must be addressed.  Section 13.3 of Identity, Securing the Connection to the
Authentication Service, brings up the important point that while direct TLS
connections are preferred, they are not feasible in all architectures. For
requests, mechanism such as auth-int can be used to add some protection, and
the identity service can always challenge a request before adding an
Identity header. There is no mechanism for challenging responses, so the
proposed mechanism can only be used when a UAC has SIPS level of trust its
DAS response identity provider.   

* using AIBs with hidden identity seems to require that the uac attempt to
fetch a certs for every entry in the via path. It could take a long time for
this to complete, and while sip-certs could be used for this it is currently
scoped to UA certificates; I don't think it includes proxy certificates.  It
also requires that FQDN entries be placed in via headers.  If only element
has a resolvable source for certificates in the via path its desire to
remain anonymous  will be compromised.

* Response-Authorization and Response-Authentication are defined in the
draft but not used

Thanks,

Derek

_______________________________________________
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