Subject: [Sip] RE: draft-ietf-sip-identity-03

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 4 Nov 2004 05:19:19 -0500

Thanks for the close reading, Paul - I know you tend to unearth a lot of
details that others miss, so I especially appreciate your taking a look at
this. A few responses inline:

> There is allusion to using this mechanism with redirect servers. But 
> there are no examples of this. At least one small thing might not work 
> great in such a case. The authentication service is required to add a 
> Date header if not already present, and then use in in the signature. 
> This won't work well for a redirect lacking Date.
> 

Well, I've been roughly assuming that the RFC3261 19.1.5 procedures could be
used to insert a Date header, if needed, but that hasn't been articulated in
the draft.

e.g.: sips:[email-masked]?Date=...

There's some ugly escaping that would be required to make that work, but I
think it's doable. Of course, it isn't documented, but as you point out,
there is merely an allusion to this today. Ultimately, I intended to take
this up as future work, given some community interest.

>   It may have need/requirement to use some other server as first hop, 
> and may or may not even have way to know which one is the auth 
> server. Requirement for UA to directly connect to auth server seems 
> unrealistic. 

Personally, I have yet to use SIP in any environment in which I have been
forced to go through some proxy as a first hop, where first hop wouldn't
reasonably be the party that should provide identity services for me. What
the draft says now, essentially, is that the mechanism is only applicable to
scenarios where a UA can connect directly to an auth service. While
long-term deployment experience may prove this scope wise or foolish, the
design choice here hasn't been made capriciously - given the security tools
available, if the UA cannot connect directly to the auth service, then we
encounter serious questions about the efficacy of the mechanism (see below).

The manner in which the UAC might determine that it is talking to an auth
service is, however, pretty straightforward. Considering the Digest
authentication case, from the UAC perspective, all it cares about is the
challenge realm. If the challenge realm matches the domain of the UAC's AoR,
and the cert acquired by TLS matches the challenge realm, then as far as the
UAC is concerned, it should authenticate itself to the server (and this is
all just standard RFC3261 behavior). Strictly speaking, there are
architectures where these conditions might be satisfied, but the auth
service would not actually be the first-hop proxy - in these cases, though,
the auth service and the first-hop proxy would be components of a common
administrative domain, and effectively would be acting as a distributed auth
service (though this is undocumented today). This loophole arises because
this mechanism is intended to be useful opportunistically - that is, without
the UAC even being aware that it is talking to an auth service. Accordingly,
the draft makes few assumptions about how UACs behave other than those
already made in RFC3261. So, ultimately it is up to the auth service itself
whether or not it adds an Identity header.

Anyway, in many environments where I imagine one might be forced to go
through a particular proxy as a first hop, that proxy is probably a good
candidate to instantiate the auth service role. If the environment of the
UAC forces a first-hop proxy, and doesn't provide auth services appropriate
for the UAC, then the environment blocks the UAC from using an identity
service. The fact that this is possible is not, I think, a strong argument
to reconsider the mechanism; in some environments, this may be the desired
effect, even.

Of course, it is also the case the UAC can act as an auth service in the
draft as written; in very constrained environments, this may be the best way
to get an Identity header.

> And requirement to send auth request over a tls connection 
> seems insufficient if there are other hops. UA can't really be sure that 
> the auth server with be the firs hopt. And it can't necessarily use sips 
> to guarantee hop by hop security till it gets there. 

Agreed, but I think it would be closer to the truth to say that the UA and
auth service cannot authenticate one another unless they are one hop apart
(I also don't think SIPS will help much). While the identity mechanism may
not be applicable to all deployment possibilities, I think it is useful as
it stands.

> How about having 
> the *UA* generate an identity header (or variant) signed somehow with 
> its digest key to protect the message on the say to the auth server? 
> (I'm not a crypto guy - maybe there is no way to make this work.)
> 

There is some merit to that idea. I mean, essentially that is what the
Proxy-Authorization header can provide (though auth-int wouldn't guarantee
integrity over the same set of headers). What you want to avoid is cases
where the UAC cannot authenticate the auth service, and a rogue challenger
launches some sort of dictionary attack to discover the Digest credentials
once it has a Proxy-Authorization header in hand. I'm not sure there's a way
to structure a UAC-generated digest for this purpose that wouldn't suffer
from this concern. To get there, we'd certainly be reinventing the majority
of what Proxy-Auth headers do. Hence the direct TLS, and the challenge-realm
matching, which insures that the UAC can authenticate the auth service. Just
handing out your digested password to any transitively-trusted proxy that
challenges you is potentially risky.

> You strongly discourage use of tel: in from:. But there are advantages 
> of tel: - that recipient can render it as a phone number, which isn't 
> really kosher if it is a sip url, even with user=phone. And return calls 
> to it are obligated to use sip via the stated domain, while with tel the 
> caller has more options.
> 

The reasons for discouraging the use of tel are given in the draft, and are
compelling, I think. As a recipient verifying the identity header, why
should you trust, say, cisco.com to authorize the use of the telephone
number '+15165551001'? There's certainly no a priori way for a recipient to
determine whether or not cisco.com is entitled to make any such assertion.
It is very clear, though, why you would trust cisco.com to authorize the use
of the name [email-masked].

There's no question that it would be useful to provide identity services for
telephone numbers. While the draft discourages their use, it doesn't forbid
it, and it leaves the door open for subsequent work to define something
here. A number of theories are circulating (like using ENUM in some
fashion), but it'll take a while to shake out.

> Hash includes digit and method portions of CSeq. Digit portion could 
> have leading zeros. As it passes thru other intermediate nodes it is 
> possible this would be parsed and regenerated, losing the leading zeros. 
> To avoid, value used here should drop redundant leading zeros.

Good catch. Will incorporate it.

> Above are really small stuff. This is looking quite feasible now.
> 

Great!

Jon Peterson
NeuStar, Inc.

> 	Paul

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Nov 2004 10:05:40 -0500

Peterson, Jon wrote:
> this. A few responses inline

> this up as future work, given some community interest.

OK. If the intent was simply to point the way for future work, then 
fine. That wasn't clear to me.

> reasonably be the party that should provide identity services for me.

What about the IMS architecture, when you are connected to a visited 
network? The P-CSCF may be able to authenticate you, but it won't be 
able to sign your identity with credentials from your home domain.

(That of course is just an example.)

 > What
> all just standard RFC3261 behavior).

Seems like the challenge realm is a red herring above. If the TLS cert 
matches the domain of my AOR then I know I am one hop away from 
something authoritative for my domain, regardless of the challenge. 
Since there could be many proxies in my domain, the challenge could be 
coming from a different one. In any case I have to forumulate the 
request before being challenged.

 > Strictly speaking, there are

Yes, this certainly is a possibility. Maybe it would help to soften the 
stance in the document, by inserting some words like those above.

> to reconsider the mechanism; in some environments, this may be the desired

The IMS case I mentioned above fits this. The UAC is forced to use a 
first hop proxy with credentials for a different (visited) domain. But 
the home domain of the UAC has a business relationship with the visited 
domain and trusts it. But I don't see any way to exploit that 
relationship so that the home proxy could safely sign the request.

I guess I agree that this might be a reason to find that connection 
mechanism to be suspect.

> to get an Identity header.

Sure. But then you are back to needing UAs with certs.

> not be applicable to all deployment possibilities, I think it is useful as

Well, if the identity mechanism can become sufficiently compelling, then 
it might rule out architectures that prevent its use.
Perhaps this is the real motivation. :-)

> challenges you is potentially risky.

As I said, I'm not a crypto guy. I was expecting that there would 
probably be some issue like this.

> determine whether or not cisco.com is entitled to make any such assertion.

I agree with the concern, but the need is still there.

> fashion), but it'll take a while to shake out.

Yes, enum does seem like it might provide a solution. Maybe this will 
have to do for now.

> Good catch. Will incorporate it.

I looked for other similar issues but didn't find any.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Nov 2004 10:42:42 -0500

One other thing occurred to me. You point out that there is some 
significant cost to the signing operation. I am thinking that this might 
be done on an as-needed basis. For instance, the proxy could first just 
pass the request along without signing it. If a 428 'Use Identity 
Header' is received in response the request could signed and retried. 
But I think there are problems with the proxy doing the retry on its 
own. It could be done under explicit control of the UAC, but then there 
would need to be a way for the UAC to request that signing be done, or not.

This might be especially interesting in an environment where 
P-Asserted-Identity is often sufficient.

	Paul