Russ Housley > Discuss (2009-10-22) > > The document only supports sha1WithRSAEncryption (se Section 9.6). > If only one is going to be supported, I greatly prefer > sha256WithRSAEncryption. This is not correct. The document only requires support for sha1WithRSAEncryption: The certificates should be consistent with [RFC5280]. A signatureAlgorithm of sha1WithRSAEncryption MUST be implemented. That doesn't mean you couldn't support sha256WithRSAEncryption. Given the implementation profiles of these algorithms, that seems appropriate. A requirement to support both would be OK, I guess. Were you asking for sha256WithRSAEncryption to be mandatory or simply allowed? > Why not reference RFC 5208 instead of PKCS#8? RSA has given change > control for PKCS#8 to the IETF, so a reference to RFC 5208 will allow > people to find any subsequent versions that the IETF might produce. The document does reference 5208. Perhaps you're concerned about Section 10.3? We'll change the reference there. ` > I saw a Last Call comment from Steve Kent asking why PKIX enrollment > protocols are not supported. I did not see a response to that query. [Robert is looking into this.] Hmm... I don't see this message. However I think the answer is that by and large the PKIX enrollment protocols aren't very congenial to the kinds of message processing that SIP UAs and registrars are prepared to do. SIP already has a whole bunch of message processing and authentication machinery, and so it's easiest to just exploit that. ================================================================================ > Lars Eggert > > Discuss (2009-10-16) > > Section 12.1., paragraph 4: > > [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography > > Specification Version 2.0", RFC 2898, September 2000. > > DISCUSS: Downref. (The one to RFC5208 was handled in last-call but not > this one?) [No response necessary - already resolved] > Comment (2009-10-16) > > Section 6.5., paragraph 3: > > Implementations which generate large notifications are reminded to > > follow the message size restrictions for unreliable transports > > articulated in Section 18.1.1 of SIP. > > It's pretty much guaranteed that NOTIFYs that have S/MIME certs in > them will be longer than 1300 bytes. It's also pretty much guaranteed > that the clients will have no idea of the PMTU. According to Section > 18.1.1 of RFC3261 this means that these will need to be sent over TCP. > How many stacks are really going to support this "upconversion" to > TCP? I was under the impression that TCP support wasn't really there? > (I may upgrade this to a discuss, but let's see.) [ignore this - Robert working on it] It's moving along. Basically, it's a requirement for a lot of NAT/FW traversal, so it's emergent, especially with the publication of outbound (RFC 5626). > Tim Polk > > Discuss (2009-10-22) > > This is a good document, and I will move to Yes once some issues have been > addressed. > > As noted in section 2: > > Certificates > that are signed by a certificate authority can also be used > with > all the mechanisms in this draft, but it is expected that they are > used purely as a key carrier and that their validity is not > checked. > > IMHO, the self-signed certificate and credential distribution mechanisms provide > a significant incremental improvement in SIP security, and provide a reasonable > transition strategy to promote use of certificates for SIP security. If > certificates signed by a trusted third party are used "purely as a key carrier" > instead of self-signed certificates, the security achieved is the same in both > cases. However, using certificates issued by trusted third parties can provide > a more robust level of security for SIP applications by leveraging the PKIX tool > set. However, the mechanisms for use with certificates from trusted third > parties are under-specified so an implementer would not know how or where to > integrate these tools into a product if they are available and the additional > security is desired. > > I would like to see an additional section in the security considerations section > that explains the incremental improvement in security provided by validating the > chain of certificates associated with the user's third party certificate, > pointing to RFC 5280. This is ekr's suggestion to address this concern: How about we change S 2: Certificate: A PKIX [RFC5280] style certificate containing a public key and a list of identities in the SubjectAltName that are bound to this key. The certificates discussed in this draft are generally self signed and use the mechanisms in the SIP Identity [RFC4474] specification to vouch for their validity. Certificates that are signed by a certificate authority can also be used with all the mechanisms in this draft, however, they need not be validated by the receiver (although the receiver can validate them for extra assurance; see Section 9.3.1). And add 9.3.1. Although the certificates used with this document need not be validatable to a trust anchor via PKIX [RFC 5280] procedures, certificates which can be validated may also be distributed via this mechanism. Such certificates potentially offer an additional level of security because they can be used with the secure (and partially isolated) certificate authority user verification and key issuance toolset, rather than depending on the security of generic SIP implementations. When a relying party receives a certificate which is not self-signed, it MAY attempt to validate it using the rules in Section 6 of RFC 5280. If the certificate validates successfully and the names correctly match the user's AOR (see Section 9.6), then the implementation SHOULD provide some indication that the certificate has been validated with an external authority. In general, failure to validate a certificate via this mechanism SHOULD no be used as a reason to reject the certificate. However, if the certificate is revoked, then the implementation SHOULD reject it. > Pasi Eronen > > Discuss (2009-10-22) > > I have reviewed draft-ietf-sip-certs-09, and have one question > that I'd like to discuss before recommending approval of the document: > > In Section 7.10, why is the credential service required to check that > one of the SubjectAltNames matches the authorized user (and the basic > constraints)? The final recipient of the certificate will not usually > use that SubjectAltName for anything (so it doesn't really matter what > it contains)... and this check would complicate using CA-issued > certificates (since it requires the credential service to know what > kinds of names that particular CA uses). > > (I will probably clear this DISCUSS after the telechat, but would > be interested in knowing the rationale behind this requirement.) > Alexey Melnikov I agree that this isn't necessary. I think it's mostly a matter of avoiding having certificates floating around whose names don't match the ostensible people the certificates vouch for. I agree that there is some uncertainty about CA name formats, but it doesn't seem to help anyone to have people try to verify a large diversity of those formats. Do you feel strongly that this should be relaxed? > Discuss (2009-10-22) > > This is a good and useful document and I support its publication. > However I have > a small set of relatively minor issues I would like to discuss first. > > 1) In Section 6.2: > etag-param = "etag" EQUAL token > > I think this needs a normative reference to RFC 5234 (ABNF). Removed section 6.2 per another comment. > <> As I reviewed this, I realized that all of the references to the etag parameter were not needed. A previous round of comments from long ago had identified this and there were still some remnants of this in the document. I have removed these references from sections 5, 6.2 (removed), 7.2 (removed), 7.8 and 10.2. Section 5 text has been changed from: If no new credentials have been received in that time, the UA creates new credentials to replace the expiring ones and sends them in a PUBLISH request (with a SIP-If-Match header field set to the current etag). This makes credential collisions both unlikely and harmless. to: If no new credentials have been received in that time, the UA creates new credentials to replace the expiring ones and sends them in a PUBLISH request following RFC 3903 rules for modifying event stage. Talk to Adam Roach to make sure the right approach has been taken to replacing a credential. Fluffy? Jason? This would take too much research for me. > 2) DISCUSS DISCUSS > > In Section 7.5: > > The NOTIFY MUST contain a multipart/mixed (see [RFC2046]) body that > contains both an application/pkix-cert body with the certificate and > an application/pkcs8 body that has the associated private key > information for the certificate. The Content-Disposition MUST be set > to "signal" as defined in [RFC3204]. > > A future extension MAY define other NOTIFY bodies. If no "Accept" > header field is present in the SUBSCRIBE, the body type defined in > this document MUST be assumed. > > Question: does the Accept header field body contains "multipart/mixed" > or > "application/pkcs8"? How would this work for future extensions if > there is a > need to return other media types inside a top level "multipart/mixed"? I'll rewrite the text of 7.5 to this: An implementation compliant to this specification MUST support the multipart/mixed type [see RFC2046]. This allows a notification to contain multiple resource documents including at a minimum the application/pkix-cert body with the certificate and an application/pkcs8 body that has the associated private key information for the certificate. The absence of an Accept header in the SUBSCRIBE indicates support for multipart/mixed and the content types application/pkix-cert and application/pkcs8. If an Accept header is present, these types MUST be included, in additional to any other types supported by the client. > 3) DISCUSS DISCUSS > > 7.10. Notifier Processing of PUBLISH Requests > > (Question to Security ADs): > Excuse my ignorance, but are there any useful checks that can be > performed to see if the application/pkix-cert body > part matches information in the application/pkcs8 body part? Answer from ekr: "Not as far as I know, b/c the key is encrypted." > 4) In Section 9.5: > > Credential services SHOULD implement the server name indication > extensions in [RFC5246] and they MUST support a TLS profile of > TLS_RSA_WITH_AES_128_CBC_SHA as described in [RFC5246] as a profile > of TLS_RSA_WITH_3DES_EDE_CBC_SHA. > > I can't parse this sentence. I agree that this is meaningless. Proposed rewrite: Credential services SHOULD implement the server name indication extensions in [RFC5246] and they MUST support a TLS profile of TLS_RSA_WITH_AES_128_CBC_SHA as described in [RFC5246]. > The PKCS#8 in the clients MUST implement PBES2 with a key derivation > algorithm of PBKDF2 using HMAC with SHA1 > > (Comment) I think this needs references to HMAC and SHA1 documents. I'm not sure what the convention here is. We didn't think we needed these since 2898 already has normative references. > Comment (2009-10-22) > > 2. Definitions > > Certificates > that are signed by a certificate authority can also be used with > all the mechanisms in this draft, but it is expected that they are > used purely as a key carrier and that their validity is not > checked. > > I find this statement to be strange, if not wrong. Adapted per Tim's comment. > 4. UA Behavior with Certificates > > The Subscriber needs to decide how long it is willing to trust that > the certificate it receives is still valid. If the certificate is > revoked before it expires, the Notifier will send a notification with > an empty body to indicate that the certificate is no longer valid. > If the certificate is renewed before it expires, the Notifier will > send a notification with a body containing the new certificate. > > It would be nice to state the assumption that there is only one certificate per > user at any given time earlier in the document. Agreed. How about in S 2 Defn. we add: "This document only supports advertising one certificate at a time for a given user." > > 5. UA Behavior with Credentials > > Credentials are created by creating a new key pair which will require > appropriate randomness, > > I think an Informative reference to RFC 4086 would be appropriate here: > > [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness > Requirements for Security", BCP 106, RFC 4086, June 2005. Sure. > 6.12. State Agents and Lists > > The certificate server described in this section which serves > certificates is a state agent and implementations of the certificate > server MUST be implemented as a state agent. > > Question: which document defines the "state agent" term? This is defined in RFC 3265. Added a reference. > 7.6. Subscriber Generation of SUBSCRIBE Requests > > The UA needs to authenticate with the credential service for these > operations. The UA MUST use TLS to directly connect to the server > acting as the credential service or to a server that is authoritative > for the domain of the credential service. The UA MUST NOT connect > through an intermediate proxy to the credential service. > > Last sentence: it would be helpful if the document pointed out > how to achieve this. The intent here is to NOT allow a third party proxy to be in between the UA and the credential service. For example, alice@example.com MUST NOT send a SUBSCRIBE request via another domain. It must send it directly to example.com. I'm not sure how to clarify this in the text. > 7.10. Notifier Processing of PUBLISH Requests > > If the Subscriber submits a PUBLISH request with no body, this > revokes the current credentials and causes all subscriptions to the > credential package to be deactivated as described in the previous > section. > > I think you need an explicit section reference number here, section 7.9 is > talking about something else. I think this points out an error in 7.10. The PUBLISH with no body revokes the current credentials but it does not cause all subscriptions to be deactivated. This must be done explicitly as outlined in section 7. Rewrite text from: If the Subscriber submits a PUBLISH request with no body, this revokes the current credentials and causes all subscriptions to the credential package to be deactivated as described in the previous section. (Note that subscriptions to the certificate package are NOT terminated; each subscriber to the certificate package receives a notification with an empty body.) to: If the Subscriber submits a PUBLISH request with no body and Expires=0, this revokes the current credentials. Watchers of these credentials will receive update with no body indicating that they MUST stop any previously stored credentials. Note that subscriptions to the certificate package are NOT terminated; each subscriber to the certificate package receives a notification with an empty body. [confirm in PUBLISH RFC ] -Ekr