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

["Peterson, Jon" <[e-mail]>]

Thanks for the read, Adam. Some responses:

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

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.

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

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

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.

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

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.

> /a
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip