Re: [Sip] WGLC on domain-certs and eku - comments on domain-certs

["Elwell, John" <john.elwell at siemens.com>]

1. "Existing SIP specifications do no sufficiently specify"
Change "no" to "not".

2. "Section 5 looks at the reason why mutual inter-domain authentication
   is desired in SIP, and the lack of normative text and behavior in
   RFC3261 for doing so.  Section 7 provides normative behavior on the
   SIP entities (user agent clients, user agent servers, registrars,
   redirect servers, and proxies) that need perform authentication based
   on X.509 certificates."
Odd that there is no mention of section 6. If there really is a need to
describe the document layout, then mention section 6 too.

3. "A domain name in an X.509 certificates"
Change "an" to "a".

4. "6.  Guidelines for a service provider

   When assigning certificates to proxy servers, registrars, and
   redirect servers, a service provider MUST ensure that the SIP AUS
   used to address the server is present as an identity in the
   subjectAltName field of the certificate."
So section 6 is "guidelines" and contains a RFC 2119 language. Whereas
section 7 is normative (according to an earlier statement) and also
contains RFC 2119 language. If they are both normative (in the way
normative is used in BCPs), then they should both be claimed as
normative. "Guidelines" seems too soft.

5. "such usage is NOT RECOMMENDED for new certificates,
   which MUST contain the identity in the subjectAltName extension"
I think we should either use a "MUST NOT" construct in the first half
together with "MUST" in the second half, or use "NOT RECOMMENDED" in the
first half and "SHOULD" in the second half.

6. "implementations must follow checks as
   prescribed therein."
Should this be "MUST"?

7. "The use of the CN value is allowed for backward compatibility,
       but is NOT RECOMMENDED"
This appears in the section on normative behaviour for a SIP entity, yet
it appears to be a recommendation applicable to certification
authorities.

8. "Alternatively,
   the server could have a list of all SIP domain names is allowed to
   accept connections from"
Change "is" to "it is".

9. "the connect-reuse [10] draft discusses this aspect in
   more detail."
I would suggest changing to "connect-reuse [10] discusses this aspect in
more detail", to cover the case where [10] becomes an RFC in time.

10. "A proxy MUST use the procedures defined for a User Agent Server
(UAS)
   in Section 7.4 when authenticating a connection from a client."
and
    "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."
But section 7.4 has the title "Server behavior" and not "UAS behavior",
and likewise 7.3 has the title "Client behavior" and not "UAC behavior".
When reading those sections I had assumed the referred to the TLS client
and server. If we were to make it clear that this is the case, we would
not require these statements in 7.5 for a proxy.

11. "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."
It think this section on registrar behavior is redundant.

12. "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 this section on redirect server behavior is redundant too.

13. "the subjectAltName MAY
   contain multiple identifiers for the Subject"
It is not the function of this draft to make normative statements
concerning what can be placed in a certificate.

14. "Since only one certificate is needed for multiple domains, the
keying
   material management is straightforward, but such a certificate MUST
   be revoked if ANY identifier in the certificate is no longer
   associated with the holder of the private key for the certificate."
This section (7) is concerned with behavior of SIP entities, yet this
seems to place a normative requirement on a certification authority.

15. "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."
This doesn't seem to fit too well with the preceding paragraphs in
section 7.8, which seem to say that one certificate can have multiple
identities, so why the need for different certificates? I think this
section needs to be made clearer.

16 "Confidentiality:  SIPS messages from alice at example.com to
      bob at example.edu can be read only by alice at example.com,
      bob at example.edu, and SIP proxies issued with domain certificates
      for example.com or example.edu."
Any SIP messages (not just those targeted at SIPS URI) expect this
property if transported over TLS.
Similarly for the next statement on integrity.

17. "8.1.  Connection authentication using Digest"
I have a problem with this section. Digest authentication, in
conjunction with TLS server authentication, is frequently used between
certain classes of UA and their outbound proxy because it is impractical
to provide those UAs with certificates. One of the functions of
sip-outbound is to help make this work. Therefore to say unconditionally
that digest is NOT RECOMMENDED is wrong.

John


> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On 
> Behalf Of DRAGE, Keith (Keith)
> Sent: 22 February 2008 07:22
> To: IETF SIP List
> Cc: Jeffrey, Alan S A (Alan); slawrence at bluesocket.com
> Subject: [Sip] WGLC on domain-certs and eku
> 
> (As WG chair)
> 
> This is to announce a WG last call on BOTH
> 
> http://www.ietf.org/internet-drafts/draft-ietf-sip-domain-certs-00.txt
> 
> and
> 
> http://www.ietf.org/internet-drafts/draft-ietf-sip-eku-01.txt
> 
> Comments should be submitted to both the list, and to the authors, by
> Friday 7th March 2008. This will give the opportunity for 
> discussion of
> major issues at the SIP WG meeting in Philadelphia.
> 
> Please clearly identify the position of any issue in the 
> internet draft,
> and if possible identify what you would like to see as a correction.
> Please also indicate the nature or severity of the error or 
> correction,
> e.g. Major technical, minor technical, NIT, so that we can 
> quickly judge
> the extent of problems with the document.
> 
> Note that both these documents are used by:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reu
se-09.txt
> 
> This particular document is finished and ready for the publication
> request, but if you feel your comment also addresses the usage by this
> document, please clearly indicate and get the comment in.
> 
> Regards
> 
> Keith
> _______________________________________________
> Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip