Subject: [Sip] Questions on the SIP identity draft

From: Simone Leggio <[email-masked]>
Date: Tue, 01 Feb 2005 10:45:56 +0200

Hi all,

I have a couple of questions about the SIP identity draft, i.e.

Enhancements for Authenticated Identity Management
in the Session Initiation Protocol (SIP)

draft-ietf-sip-identity-03

1) In the background section, I quote:
>  Note that the scope of this
>    document is limited to providing this identity assurance for SIP
>    requests; solving this problem for SIP responses is more complicated,
>    and is a subject for future work.

Why can't SIP Identity be applied to responses as well? Why can't an 
Identity header field be added based on the relevant response fields? At 
least, final responses like 200 OK.
For more security, instead of adding only the addr-spec component of the 
To header field, it may be added also the tag part. Am I forgetting some 
relevant security issue?

2) Section 10 says that

> The REGISTER method uses Contact header fields in very unusual ways that
>    complicate its applicability to this mechanism.  Accordingly, the
>    Identity and Identity-Info header MUST NOT appear in REGISTER

Why can't the REGISTER be protected? Usually authentication happens 
because user agent and server share a common secret, i.e. password. What 
if they would share a key? The user agent signs the REGISTER with its 
key, and the server uses it for verifying the identity of the 
authenticating entity. Of course, the user agent has communicated 
previously its key to the server, probably when the user registers for 
the first time in that SIP domain. Anyway, how key communication is 
performed would be out of scope for SIP Identity.

Best regards,

	Simone Leggio

_______________________________________________
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: "Peterson, Jon" <[email-masked]>
Date: Wed, 2 Feb 2005 19:56:00 -0500

Hello Simone,

> I have a couple of questions about the SIP identity draft, i.e.
<snip>
> least, final responses like 200 OK.

The answer is that it is possible to do so, but this won't be specified in the current sip-identity draft.

The scope of the sip-identity mechanism is to prevent certain trivial impersonation attacks that arise primarily in requests. It is much easier for me to impersonate the source of a request than it is for me to impersonate the destination of the request; the former just requires me to erroneously populate the From header field, the latter, however, requires me to know that a request is in process, intercept it, formulate a plausible response, and submit it in such a way that any genuine response is squelched or something. The level of sophistication required for response impersonation is far greater than that of request impersonation.

Accordingly, we felt that it was valuable to do request identity alone. Since there is some amount of controversy surrounding possible approaches to response identity, we've left this as an item for future work in the current identity draft. Expect to see response identity work sometime soon.

> if they would share a key? 

As you note, REGISTER is currently protected by the Digest authentication system in SIP. sip-identity leverages Digest when the authentication service role is instantiated by an intermediary - that is, the same Digest credentials that we be used in REGISTER are given to an authentication service in order to get an Identity signature. Thus it would be kind of pointless to use sip-identity to secure REGISTER when the authentication service is instantiated by an intermediary.

Since it is possible, and sufficient, for a user agent to authenticate itself to a registrar via Digest, I saw no reason to go out of our way and recommend a second potential mechanism for authenticating the source of a registration.

> The user agent signs the REGISTER with its 
> authenticating entity. 

I hear what you're saying (this is a case where the user agent instantiates the auth service role), but sip-identity is based on a concept of namespace authorization. The identity that you prove is a URI, and URI has a host portion - like sip:[email-masked]. To sign an Identity header, one must have a certificate (not just a key) whose subject corresponds to the host portion of the identity which you want to sign (e.g. example.com). When a UA registers, it is associating itself with an AoR controlled by a registrar (say, the regisrar of example.com, where the user is 'jon'). But if the AoR of a user is controlled by a registrar, it is rare that the user will possess the certificate for that AoR - which is necessary in order for it to act as an auth svc for that AoR.

At a high level, I guess it would be possible to do this, but it would have very limited applicability, and it doesn't seem to fill any holes in SIP's security story.

Jon Peterson
NeuStar, Inc.

> Of course, the user agent has communicated