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

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 5 Nov 2004 15:20:21 -0500

Looks like we're on the same page about most of these matters. A few more
notes.

> > 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 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.
> 

Well, I can't say that I've used SIP in an IMS environment yet, but, your
point is taken. I have a further action item, just as an aside, to describe
interworking between RFC3325 (PAI) environments and sip-identity-0x
environments, once we've agreed on exactly what sip-identity-0x entails. I
think that in many such cases, there might be some sort of edge gateway that
provides the Identity header on behalf of the whole transitively-trusting
federation. 

While I would love to see sip-identity-0x implemented for IMS, as you point
out the whole concept of 'roaming' is somewhat antithetical to the idea that
a user agent associates with their own domain. The fact that some entity
outside your local domain is authenticating you is the first warning sign,
the presence of transitive trust is the second. Roaming is based on
transitive trust. sip-identity-0x is not. Gatewaying may be the best we can
do.

> > 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).
> 
> 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.

The realm is significant because it is possible that your request will be
proxied to some other server that issues a challenge for a realm other than
your local domain. The realm tells you, essentially, which credentials you
need to provide. So, the fact that you received a 407 over a TLS connection
doesn't necessarily mean that you are being challenged by your local domain.
Further to this point, you local domain could institute a policy to inspect
the realm of challenges resulting from proxied requests in order to guard
from malicious domains down the pike fishing for passwords in your domain.

> > So, ultimately it is up to the auth service itself
> > whether or not it adds an Identity header.
> 
> Yes, this certainly is a possibility. Maybe it would help to soften the 
> stance in the document, by inserting some words like those above.

Maybe you're right; it could be worthwhile incorporating a little language
along these lines to explain that given the need to rely on opportunistic
UAC behavior, authentication services necessarily have a bit of leeway. It
may help in some architectures, though I'm not sure it'll help a great deal
in others.

> > While the identity mechanism may
> > not be applicable to all deployment possibilities, I think it is useful
as
> > it stands.
> 
> 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. :-)
> 

In the Machiavellian sense of pulling a fast one on the community, this
isn't the motivation. But there is a deeper sense in which genuine security
for SIP is possible in some deployment architectures and not possible in
others. We would do ourselves a disservice, from a security perspective, by
building an identity mechanism that is applicable to every imaginable
deployment, since in many imaginable deployments, identity cannot be
asserted securely. I'd rather have the identity assertion when it's
possible, and know that the assertion is meaningful, than allow the
assertion to appear in absolutely every case, but never really know whether
or not it is actually meaningful.

Jon Peterson
NeuStar, Inc.

_______________________________________________
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: Cullen Jennings <[email-masked]>
Date: Fri, 05 Nov 2004 21:21:50 -0800

>> able to sign your identity with credentials from your home domain.

Thought I mostly agree, it might be possible that the roaming operator does
have the private key from the home operator. Once you have theses operators
that trust each other and delegate certain operations back and forth,
something like this might work.