Subject: [Sip] WGLC on domain-certs and eku

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 22 Feb 2008 08:21:36 +0100

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

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 28 Feb 2008 16:50:03 +0000

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 [email-masked] to
      [email-masked] can be read only by [email-masked],
      [email-masked], 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: [email-masked] [mailto:[email-masked]] On 
> Behalf Of DRAGE, Keith (Keith)
> Sent: 22 February 2008 07:22
> To: IETF SIP List
> Cc: Jeffrey, Alan S A (Alan); [email-masked]
> Subject: [Sip] WGLC on domain-certs and eku
> 
> (As WG chair)
> 
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 28 Feb 2008 16:52:41 +0000

1. "Certificates whose purpose is to
   bind a SIP domain identity without binding other non-SIP identities
   MUST include an id-kp-SIPdomain attribute."
I have several comments on this statement.
a) It seems premature to make this statement prior to the explanation
that occurs in 3.1.
b) Is "MUST" appropriate at this stage, or would it be more appropriate
to include such normative language later in the document, e.g., in
section 5?
c) It looks like it might be in conflict with the later statement:
"Whether or not to include this restriction is
   up to the certificate issuer"

2. "but if it is included, it MUST be
   marked as critical"
Wouldn't this be more appropriate in section 5?

3. "3.  If any EKU is present and contains both
id-kp-anyExtendedKeyUsage
       and id-kp-sipDomain, accept the certificate."
This may be my lack of expertise in this area, but isn't there another
case where id-kp-sipDomain is present but id-kp-anyExtendedKeyUsage is
not present? If so, how is this handled. Similarly in the normative text
that precedes this descriptive flow.

John