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

[Adam Roach <[e-mail]>]

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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip