This document is looking much improved from previous drafts, thanks. Two main comments:
1. mid-dialog request handling relative to certificates is only briefly mentioned and potentially a big can of worms - needs to be clarified 2. unclear whether the recommendations in this document would allow SIP proxies to obtain certificates from EXISTING CAs in the same format they give out certs for web servers. Can you clarify that? Specific comments: > 4. SIP domain to host resolution > > Routing in SIP is performed by having the client execute RFC 3263 [5] > procedures on a URI, called the "Application Unique String (AUS) > (c.f. Section 8 of RFC 3263 [5]). These procedures take as input a Actually AUS is part of the DDDS mechanism, which was informative at the time of publicaiton of rfc3263. So that section is quite under-defined and not what most folks actually use. So if you are going to use this you should describe more clearly what it is and give an example. Section 4: is this meant as an overview? it gives an example but doesn't ahead of time actually overview the mehanisms that are proposed. If it is meant to be an overview it should be labeled as such and include an overview. Similar comment on section 5 - I'm not sure whether this section is supposed to just identify a problem, or what? Section 6: I think you need to define what you mean by 'service provider' here. You're talking about a CA in fact, no? Also what does "present" mean? Do you mean sip:example.com has to appear? Just example.com? is a subdomain OK? This is underspecified. > URI If the scheme of the URI value is 'sip' (URI scheme tokens > are always case insensitive), and there is no userinfo > component in the URI (there is no '@'), then the hostpart is a you introduce this term, "sip domain identity" here without definition - is this an AUS? Something else? > The above procedure yields a set containing zero or more identities > from the certificate. how does it yield more than one? that wasnt clear. > When comparing two values as SIP identities: Now you have this term, "SIP identities". Terminology is very unclear here. Also you might want to point out when this comparison occurs. Are you talking strictly about client authentication of server? > A client uses the SIP AUS (the SIP domain name) Now you have the term, "SIP domain name". More terminology that needs to be defined or simplified. > The server MUST obtain the set of SIP domain identities from the > client certificate as described in Section 7.1. Because the server > accepted the TLS connection passively, unlike a client, it does not > possess an AUS for comparison. Nonetheless, server policies can use > the authenticated SIP domain identity to make authorization > decisions. how can you make this a MUST if the usage of that infomration is strictly based on authorization POLICY? > Proxy behavior > > A proxy MUST use the procedures defined for a User Agent Server (UAS) > in Section 7.4 when authenticating a connection from a client. > > A proxy MUST use the procedures defined for a User Agent Client (UAC) > in Section 7.3 when requesting an authenticated connection to a UAS. this is redundant since 7.4 and 7.3 just say client and server which includes proxies. > If a proxy adds a Record-Route when forwarding a request with the > expectation that the route is to use secure connections, it MUST > insert into the Record-Route header a URI that corresponds to an > identity for which it has a certificate; if it does not, then it will > not be possible to create a secure connection using the value from > the Record-Route as the AUS. won't I have already sent the request as a client and thus opened and used the tls connection, before a mid-dialog request shows up? Or are you suggesting that, after a TLS connection is up, the client is supposed to check the existing TLS cert for the other side against the domain part of the Route URI?? This whole area - mid dialog transactions - seems underspecifeid in terms of how it relates to certificates (if at all). > 7.6. Registrar behavior > > A SIP registrar, acting as a server, follows the normative behavior > of Section 7.4. When it accepts a TLS connection from the client, it > present its certificate. Depending on the registrar policies, it may > challenge the client with HTTP Digest. > > 7.7. Redirect server behavior > > A SIP redirect server follows the normative behavior of Section 7.4. > It may accept a TLS connection from the client, present its > certificate, and then challenge the client with HTTP Digest. I think you can delete these and just mention in 7.3/7.4 that client/server encompasses registrars and redirect servers. > The TLS extended client hello [7] allows a TLS client to provide to > the TLS server the name of the server to which a connection is > desired. Thus, the server can present the correct certificate to > establish the TLS connection. So is there a normative statement here somewhere? Is this reference mandatory to implement for clients in order to allow virtual hosting? > 8. Security Considerations > > The goals of TLS (when used with X.509 certificates) include the > following security guarantees at the transport layer: this section is kind of mother-hood-and-apple pie kinds of statements on why TLS is nice. I think it should actually discuss the considerations around the SPECIFIC topics discussed here. Those have to do with binding the target of the request to the cert. The draft should discuss the attacks possible if this is not fixed and why this draft fixes that. > 8.1. Connection authentication using Digest > > Digest authentication in SIP provides for authentication of the > message sender to the challenging UAS. As commonly deployed, it This section seems out of place here. What does it have to do with TLS domain certificate conventions and usage?? -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group [EMAIL PROTECTED] http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
