Subject: [Sip] comments on draft-ietf-sip-domain-certs-00

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 13 Mar 2008 09:33:13 -0400

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