Subject: [Sip] Re: I-D ACTION:draft-ietf-sip-identity-03.txt

From: Adam Roach <[email-masked]>
Date: Sat, 06 Nov 2004 18:23:26 -0600

This looks really solid. In response to Dean's earlier query, I suspect 
this is quickly reaching "ready for WGLC" status.

When looking over this, though, there are two issues that might need a 
bit more text (although one is really more of a nit).

The first issue revolves around proxy validation of received requests 
which contain authenticated identity headers, and how these proxies 
communicate with the user who is the target of the request, and has two 
sub-issues.

Primary among these is a question of how the proxies communicate 
discrepancies to the recipient. Section 7 requires:

>    Additionally, the Date, Contact and Call-ID headers MUST be analyzed
>    in the manner described in Section 14; recipients that wish to verify
>    Identity signatures MUST support all of the operations described
>    there.  Any discrepancies or violations MUST be reported to the user.

If I implement a proxy, it is not clear how I can satisfy this second MUST.

A secondary sub-issue arises from the mechanism by which the proxy 
decides to trust certificates. There is nothing in the current draft 
that suggests, for example, that trusting self-signed domain certs for 
the purposes of user authentication might be a Really Bad Idea. (Obvious 
to security wonks, maybe not so much for your average implementor). The 
reason this ties into user interaction is that it becomes unclear how a 
proxy should react if it receives a request; that request has an 
authenticated identity asserted by a domain; and the root CA for the 
domain's certificate is not known. With user applications, this is 
typically handled by saying, "I don't know who blackhelicopers.org is, 
but they signed this certificate. Click here to examine the cert 
yourself, and let me know if I should accept this cert as invalid, 
temporarily valid, or permanently valid." When the check is performed by 
a proxy, such interaction is really quite difficult. The best a proxy 
can do is reject the request with a 428 (which seems a bit extreme), or 
let it through (in which case the proxy's check serves little to no purpose)

So, I suggest that the draft probably needs a little more text around 
proxy handling of requests; further, given the all-or-nothing nature of 
proxy validation of authenticated identity, we might consider 
discouraging its use in favor of client validation.

The second issue is a tiny nit in that the current draft doesn't specify 
what to do if you receive a request with an Identity-Info header which 
contains a URI with a scheme other than sips: or https:. Presumably, 
recipients should 428 such requests? 400?

/a

_______________________________________________
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: Mon, 8 Nov 2004 10:24:55 -0500

Thanks for the read, Adam. Some responses:

> > Any discrepancies or violations MUST be reported to the user.
> 
> 

Agreed, that should be clarified. Furthermore, this is normative behavior
about authorization decisions that will be made given the presence/absence
of identity in a message, and technically, such authorization is outside the
scope of the document.

> to security wonks, maybe not so much for your average implementor).

Really, the text should be more specific about this, and it will be. While
we shouldn't go so far as to identify particular root CAs that need to be
supported, we intend for these to be publicly-verifiable certificates.

> The 

Clearly, client validation is a superior option, yes. But, I do think there
are some authorization policies that are best implemented at a domain level,
and it is reasonable for intermediaries to instantiate those policies rather
than receiving user agents. We do need to solve for the case of how that
authorization decision will be executed, but as I've said, authZ should be
outside the scope of this draft for the most part. The only sort of authZ
action that we could reasonably expect an intermediary to perform is to
reject the request in some fashion, as you suggest.

> recipients should 428 such requests? 400?

Yeah, I think I'm going to relax that restriction for other reasons (there
is at least one other URI type, "cid:", that I think would be useful here).
Ultimately, I think that if you can dereference the URI and acquire the
necessary keying material, you shouldn't complain. There should be an error
response that says, "I can't find dereference that URI" (maybe because I
don't support the scheme, maybe because the link is broken, etc). We know we
also want to describe the case where the root CA is unsupported (and
subsumed under that, the possibility that the cert used to generate the
identity digest sig is self-signed). Identifying response codes for these
conditions is needed, I agree.

Jon Peterson
NeuStar, Inc.