Dear Eric, SIP participants:
I don't want to argue on the overall question of EE self-signed
certificates for SIP security requirements. However, some basic facts
should be noted, if only for the record.
The basic TLS handshake has some "features" which are noteworthy in the
present context:
1) The TLS protocol provides no direct support for EE public keys that
are not conveyed in X.509 security certificates.
2) The TLS protocol Certificate Request message does not allow a server
to announce its willingness to accept at once EE self-signed
certificates and a list of trusted CA names.
3) This leaves a server operator wishing to support EE self-signed
certificates *and* a list of trusted CA names with the following dilemma:
a) it announces its list of trusted CAs in the Certificate Request
message and fails to support the EE self-signed certificate mechanism, or
b) it announces its willingness to accept any CA in EE certificates
returned by clients, and then will experience EEs returning
certificates issued by untrusted CAs.
Obviously, this is a property of the TLS protocol not specific to SIP.
Point 1) is the basic issue. Point 2) arises when the EE self-signed
certificate mechanism is introduced as a hack for point 1). Point 3) is
a side-effect of this hack.
The SIP security framework requires a solution to 1). This requirement
is parhaps not unique. The selection of the EE self-signed certificate
hack should be done under full disclosure of the above, plus the
availability of another hack contributed at the start of this thread.
Regards,
--
- Thierry Moreau
Eric Rescorla wrote:
At Fri, 25 Jul 2008 11:13:22 -0500,
Thierry Moreau wrote:
Eric Rescorla wrote:
At Fri, 25 Jul 2008 09:56:53 -0500,
Thierry Moreau wrote:
Anyway, my comment is about DTLS protocol compliance and the use of
self-signed certificates. Maybe there are things I don't see, but I
wonder if the envisioned use of self-signed certificates is compliant
with DTLS, even assuming the "legitimacy" of accepting self-signed
certificates without a strong trust base in the PKI spirit.
It's explicitly compliant with DTLS. Here's what RFC 4346 says about
certificates (S 1)
the decisions on how to initiate TLS
handshaking and how to interpret the authentication certificates
exchanged are left to the judgment of the designers and implementors
of protocols that run on top of TLS.
Here are the technical details. I assume the DTLS server protocol entity
"S" wishes to accept either "self-signed" EE certificates or
certificates issued by a couple of trusted CA (requirement R-EXISTING).
"S" would send a DTLS certificate request message containing either an
empty list of CA distinguished names (meaning "I accept any CA") of a
list of CA distinguished name (meaning "I trust these CAs"). In the
latter case, the DTLS client protocol entity "C" would not be allowed to
send a self-signed EE certificate. In the former case, "C" would be
allowed to send any certificate it has on hand, including a self-signed
EE certificate.
Yes, both of these are legal in this instance. The basic setting
is one in which any certificate is accepted, but implementations
could of course be configured to require 3rd party certificates.
A) State explicitly that the empty list of CA distinguished names (in
DTLS certificate request messages) option applies. It is then preferable
to describe the self-signed EE certificate as a special case of e.g.
"any X.509 security certificate holding a public key that the end entity
controls (of which the end entity controls the private key counterpart)".
I don't have a problem with indicating that the server should
provide a compatible CertificateRequest message, but honestly
I think this is redundant, since DTLS/TLS specify how to construct
the CertificateREquest.
It's not the server behavior that would benefit from a document
clarification, it's the client's behavior. If the CertificateRequest
message contains an empty list of distinguished names, it is valid for
the client entity to send EITHER 1) a self-signed security certificate
or 2) any certificate holding a public key it controls. The document
ambiguity, as it stands, is whether 2) is allowed in the two drafts as
it is in the bare DTLS.
I don't think it's ambigous, but I'll try to add some clarifying
text.
B) Specify a public domain private key value (i.e. breached, snake-oil,
meaningless ...) and a dummy CA distinguished name for the corresponding
public key and let the EE auto-issue an X.509 certificate under this CA
as a replacement of certificate self-signature.
I don't think this is that great an idea. The semantics of self-signed
certs are commonly understood and I don't think this adds much
value.
It would allow a server to announce its preferred trusted CAs
(fulfilling R-EXISTING) *AND* its willingness to accept "auto-issued"
certificates. An EE having (genuine) certificates from CA-1 and CA-2
would select among these two per server expressed preferences. I guess
you see the point.
Yes, this seems to me to be of relatively modest value. In any
case, this is a feature which could easily be added at some point
in the future if such a fake CA ever existed.
-Ekr
_______________________________________________
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
