What is Mutual Authentication
Most sites that I have seen simply regurgitate the mutual authentication process without explaining it. I’m taking a different approach here, I’ll explain what it is in simple terms. If you need painful detail, pick one of those sites.
Mutual Authentication is sometimes called 2 Way authentication. It involves proving the identity of both parties involved in the transaction. Identity is proven using X.509 Digital certificates. There are two important points in Mutual Authentication:
Each X.509 certificate issued by a Central Authority (or trusted third party) has a digital signature. That specific signature is solely for the purpose of establishing the identity of the client at the time that the certificate was issued. It makes no guarantee that whomever currently posesses the certificate is the identity to whom the certificate was issued. That part is simply assumed to be true.
Another digital signature may be added to the certificate during the SSL handshake. There are two important points to be concerned with:
The digital signature is used to determine whether or not the certificate information has been tampered with during transmission.
The digital signature is used to help transition from the costly but secure asymmetric encryption to the much less costly but more insecure symmetric encryption.
During the SSL handshake, the server will provide a copy of its certificate to the client and the client will return the favor by providing its certificate to the server. Steps 1 and 2 above apply to each certificate.
If items 1 and 2 are validated and proven to be true, AND assuming that standards are in place to protect the PKI infrastructure that underpins the SSL framework, both parties may reasonably assume that the certificate is valid and that both parties being mutually authenticated are who they claim to be.
Did you notice the big assumption? Consider that 1 and 2 are true but one client gives a copy of the certificate with its private keys to another party B. It then necessarily follows that this new party B assumes the identity of that client! So, this is why you need standards in place to govern certificates and the PKI infrastructure so that the key assumptions described previously can ring true.
In my example, standards would govern the distribution of private keys to other parties. I use the word govern because it may well be your intention to distribute the private keys to other parties. One example would be in a server farm where the other servers in the farm would need to assume a single identity for SSL purposes. Otherwise, governance would ensure that private keys are stored and secured appropriately such that these secrets do not fall into the hands of unauthorized users.
That’s all you really need to know to understand Mutual Authentication.
What is Server Authentication
Server Authentication is sometimes called 1 Way authentication. It is the basic requirement of SSL – more precisely TLS which is part of the SSL framework. The server is required to prove its identity to all parties. It does so by using the Central Authority’s digital signature on the certificate. As explained above, that digital signature establishes the identity of the server. 1 Way authentication also issues another signature during the SSL handshake. It serves the same purpose as in mutual authentication; it is responsible for non-repudiation and protocol transition from asymmetric to symmetric encryption.WCF Mutual Authentication
Once the SSL exchange is completed, the secure channel is finalized and the browser adds the https in the URL. From that point on, the conversation is protected from unauthorized access. While it is possible to see the traffic during transmission, it is encrypted and safe from eaves dropping.
Mutual authentication with WCF is not entirely straight forward. Here are some guidelines to help with interoperability.
Map certificates only when you require resource acquisition e.g., file updates etc. Mapped certificates require knowledge of the AD account or the IIS Server Account, or when you require the security context of the mapped account.
Certificate Mapping is ignored by default; it must be explicitly turned on in IIS. Follow this link to turn it on. http://support.microsoft.com/kb/313070
Map certificates at either the IIS or Active Directory level. Active Directory introduces another level of calling overhead. IIS mapping is straightforward. Use AD mapping to authenticate when you must authenticate the user/client certificate.
A few requirements for AD Mapping:
1. Client Certificate must meet one of the following issues:
a. Should have a Subject Alternative Name field with Principal=[Users UPN] – Entrust certs that are installed on my machine do not currently meet those requirements.
b. The users certificate needs to be imported into the users account in Active Directory.
2. The users issuing CA must be in the NTAuth store within Active Directory. Once the CA certificate is in the NTAuth store in active directory the certificate should migrate down to the IIS web servers NTAuth store.
This can be validated by typing the following command on the IIS web server: CertUtil -enterprise -store NTAuth > NTAuth.txt
NOTE: Once that has been done, open the NTAuth.txt file and look for the Issuing CA to be listed in the text file.
3. The client certificate must have Client Authentication as one of the listed Enhanced Key Usages.
4. When using Client Certificate mapping, if your application must impersonate the user off box then you will need to configure Kerberos Constrained Delegation with Protocol transition for this to work.
Mapped certificates require that the calling identity be packaged within the security context. That packaging includes a performance hit.
IIS v. AD mapping
IIS Certificate mapping provides calling code access to the security context. It also allows calling code to impersonate the mapped account.
In addition to the above listed, Active Directory mapping allows the authentication of the client via the authoritative store (assuming AD is used as such).
AD Certificate mapping is a one to one mapping meaning that a certificate maps to one user account only. If you want to map 1 certificate to a group or a list of certificates to a group then you need to use the certificate mapping within IIS.
helpful configuration settings for the service:
<authentication certificateValidationMode=”ChainTrust” revocationMode=”Online” />
Or you can replace the <authentication> tag with this as well (keeping the rest the same). mapClient… forces IIS AD mapping which results in a 403 error since AD credentials is not known on the local IIS Server.
authentication mapClientCertificateToWindowsAccount=“false“ />
Trusted Subsystem or Delegation architecture.
Use the delegation architecture model when your back-end needs to know who or what on the front end is calling. Delegation architecture does not scale well.
Use the Trusted Subsystem for everything else especially if you need to manage access rights to the back-end. It is the most scalable approach. Combine this option with application level authorization to know who wrote what.
Avoid Peer Trust. It does not scale well and is not supported in IIS. Peer Trust is only supported when WCF is self-hosted.
Use Chain Trust. It is the most scalable approach and is supported by Windows infrastructure.
Strengthen your chain trust by implementing offline administrative policy to define who receives a certificate.
Strengthen your chain trust by implementing multiple levels of intermediates. Know that these levels carry a performance penalty.