Strong Authentication Infrastructure
This page describes security infrastructure components that are used by many of the Isode products. Along with the page on SASL (Simple Authentication and Security Layer) and the page on TLS (Transport Layer Security) this describes all of the infrastructure of the Isode products that use cryptography.
X.509 and Strong Authentication
X.509 describes an approach to providing and managing authentication using asymmetric cryptography, generally referred to as Public Key Infrastructure (PKI). X.400 and X.500 defined authentication mechanisms using X.509 PKI, which these standards referred to as "strong authentication". Isode uses the terms strong authentication to mean authentication based on X.509 PKI. This is common usage of the term, although it is sometimes used to refer to other technologies.
A summary of X.509 based PKI is given in the Isode whitepaper [A Short Tutorial on Distributed PKI], a general description of the benefits of strong authentication can be found in the whitepaper [The Security and Administrative Benefits of using X.509 PKI based Strong Authentication] and an explanation of X.509 concepts and terminology can be found here.
X.509 is used by Isode's products. Isode's security infrastructure includes:
- Libraries to enable applications to perform X.509 verification in support of strong authentication.
- Encrypted storage of private key and certificates in a PKCS#12 format file.
- Certificate and CRL cache.
- Infrastructure common to various Isode management tools, that enable setting up of X.509 credentials for a client or server, and interaction with a Certification Authority (CA) using PKCS#10 Certificate Signing Requests. This enables use of Isode products with most CAs, including the Isode Sodium CA.
- Sodium enables generation of PKCS#10 CSRs for objects stored in the directory, to facilitate setup of X.509 configuration Sodium and Sodium CA are designed to work closely together.
X.509 is used in many of Isode’s products and includes support for the following protocols and services.
- X.400: P1 strong authentication and X.400 end to end services for content integrity, message origin authentication and message sequence integrity.
- X.500: Signed Operations and Peer Authentication for DAP, DSP and DISP.
- SMTP, IMAP and POP.
- XMPP C2S and S2S protocols.
Authentication used with Transport Layer Security
Transport Layer Security (TLS) is an Internet Standard for providing data confidentiality, and is used by Isode. TLS provides strong authentication using X.509 Certificates. Internet messaging and directory protocols make use of SASL to provide authentication services. When X.509 based authentication is used by messaging and directory protocols, the SASL authentication is made available to the application by the "SASL External" mechanism. This means that the application authenticates within the SASL framework, but uses the underlying TLS X.509 authentication to provide the authentication service. TLS provides two X.509 based authentication mechanisms:
- Client Authentication. Where a client application is authenticated by a server (e.g., For an LDAP server to verify the identity of a client).
- Server Authentication. Where the identity of a server is authenticated by a client (e.g., for an LDAP client to ensure that it is talking to the correct server).
Use of Directory
X.509 PKI can use the directory for two important functions: CRL retrieval and certificate path building. These are described in the Isode whitepaper [Distributed Directory in support of Large Scale PKI] and are supported by the Isode products for Strong Authentication in the OSI protocols and for Signed Operations. Isode’s X.509 infrastructure uses LDAP to access a directory server to achieve this functionality, except in the M-Vault product where direct internal access is used.
Isode’s X.509 verification can use certificate revocation checking using OCSP (Online Certificate Status Protocol) and by checking CRLs (including delta CRLs), which we can retrieve using LDAP and HTTP. M-Vault will use native retrieval when the CRLs are being stored locally.
OCSP Trusted Responder support is present for M-Vault and M-Link. Additionally, they can both be configured not to use other kinds of retrieval, meaning that it can be used in an environment requiring revocation checking and relying entirely on a local OCSP responder.
Subject Alternate Name Support
X.509 certificates use Subject Alternate Names to support name forms appropriate to different applications. Isode’s X.509 infrastructure and GUIs provide flexibly Subject Alternate Name support, and in particular supports RFC 6125 conformance for all of the Isode supported protocols.
Isode infrastructure uses the following cryptographic algorithms. Note that SHA224, SHA256, SHA384, SHA512 are not currently supported for X.500 (DAP and Signed Operations) and X.400 (Strong Authentication, MOAC and Token).
Supporting Hash Algorithms
|RSA||MD5; SHA1; SHA224; SHA256; SHA384; SHA512|
|DSA||SHA1; SHA224; SHA256; SHA384; SHA512|
|ECDSA||SHA1; SHA224; SHA256; SHA384; SHA512|
Strong Authentication Conformance
Isode products conform to the following standards for strong authentication, including management:
|ITU-T Recommendation X.509 (1997 E)||Information Technology - Open Systems Interconnection – The Directory: Authentication Framework, June 1997.|
|RFC 5280||Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, May 2008|
|RFC 6125||Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS), March 2011|
PKCS (Public-Key Cryptography Standards) published by RSA Labs:
|PKCS#10||Certification Request Syntax Standard – Version 1.7|
|PKCS#12||Personal Information Exchange Syntax Standard – Version 1.0|
Isode makes use of the OpenSSL package to provide:
- Transport Layer Security (TLS).
- The X.509 used by applications making use of TLS.
- The cryptography in support of all Isode X.509 implementations
OpenSSL has FIPS 140-2 conformance which is a US government security standard for cryptographic modules defined here. Note that OpenSSL is only FIPS 140-2 compliant in certain configurations. Isode currently claiming FIPS 140-2 compliance for M-Link, but not for any other products. OpenSSL is a high quality package used by many commercial products. Isode would like to acknowledge the contribution from the authors of OpenSSL, and of the organizations that have funded work on these packages.
There is also a strong security benefit in using open source technology, particularly for the cryptographic components. Because the source is widely used and openly available, it has been subject to substantial peer review. This leads to a high confidence in the security of these products. Isode tracks versions of OpenSSL, and in the event of security fixes to OpenSSL which may Impact Isode products, will release product updates.
Isode’s Sodium CA and other GUIs make use of Bouncy Castle Java libraries for display and manipulation of objects. Strong authentication and X.509 verification uses the same code as the servers.
Sodium CA uses Bouncy Castle Cryptography Provider for its PKI functions.