Category: Network Security Protocols

Benefits of TLS for Issuing and Presenting Cryptographic Credentials

In comments on the previous post at the Identity Commons mailing list and comments at the session on deployment and usability of cryptographic credentials at the Internet Identity Workshop, people have questioned the advantages of running cryptographic protocols for issuing and presenting credentials inside TLS, and argued in favor of running them instead over HTTP. I believe running such protocols inside TLS removes several obstacles that have hindered the deployment of cryptographic credentials. So in this post I will try to answer those comments.

Here are three advantages of running issuance and presentation protocols inside TLS over running them outside TLS:

  1. TLS is ubiquitous. It is implemented by all browsers and all server middleware. If issuance and presentation protocols were implemented inside TLS, then users could use cryptographic credentials without having to install any applications or browser plugins, and developers of RPs and IdPs would not have to install and learn additional SDKs.
  2. The PRF facility of TLS is very useful for implementing cryptographic protocols. For example, in the U-Prove presentation protocol [1], when U-Prove is used for user authentication, the verifier must send a nonce to the prover; if the protocol were run inside TLS, that step could be avoided because the nonce could be independently generated by the prover and the verifier using the PRF. The PRF can also be used to provide common pseudo-random material for protocols based on the common reference string (CRS) model [2]. (Older cryptosystems such as U-Prove [1] and Idemix [3] rely on the Fiat-Shamir heuristic [4] to eliminate interactions, but more recent cryptosystems based on Groth-Sahai proofs [5] rely instead on the CRS model, which is more secure in some sense [6].)
  3. Inside TLS, an interactive cryptographic protocol can be run in a separate TLS layer, allowing the underlying TLS record layer to interleave protocol messages with application data (and possibly with messages of other protocol runs), thus mitigating the latency impact of protocol interactions.

And here are two advantages of running protocols either inside or directly on top of TLS, over running them on top of HTTP:

  1. Simplicity. Running a protocol over HTTP would require specifying how protocol messages are encapsulated inside HTTP requests and responses, i.e. it would require defining an HTTP-level protocol.
  2. Performance. Running a protocol over HTTP would add the overhead of sending HTTP headers, and, possibly, of establishing different TLS connections for different HTTP messages if TLS connections cannot be kept alive for some reason.

As always, comments are welcome.

References

[1] Christian Paquin. U-Prove Cryptographic Specification V1.1 Draft Revision 1, February 2011. Downloadable from http://www.microsoft.com/u-prove.
 
[2] M. Blum, P. Feldman and S. Micali. Non-Interactive Zero-Knowledge and Its Applications (Extended Abstract). In Proceedings of the Twentieth Annual ACM Symposium on Theory of Computing (STOC 1988).
 
[3] Jan Camenisch et al. Specification of the Identity Mixer Cryptographic Library, Version 2.3.1. December 2010. Available at http://www.zurich.ibm.com/~pbi/identityMixer_gettingStarted/ProtocolSpecification_2-3-2.pdf.
 
[4] A. Fiat and A. Shamir. How to Prove Yourself: Practical Solutions to Identification and Signature Problems. In Proceedings on Advances in Cryptology (CRYPTO 86), Springer-Verlag.
 
[5] J. Groth and A. Sahai. Efficient Non-Interactive Proof Systems for Bilinear Groups. In Theory and Applications of Cryptographic Techniques (EUROCRYPT 08), Springer-Verlag.
 
[6] R. Canetti, O. Goldreich and S. Halevi. The Random Oracle Methodology, Revisited. Journal of the ACM, vol. 51, no. 4, 2004.
 

Pomcor’s Comments on the Cybersecurity Green Paper

We have written a response to the Call for Comments on the report entitled Cybersecurity, Innovations and the Internet Economy, written by the Internet Policy Task Force of the US Department of Commerce.

In the response we call for research and development efforts aimed at improving and broadening the scope of the TLS protocol (formerly known as SSL). This would benefit NSTIC and the many IETF protocols that rely on TLS for their security.

If you have any comments on our response, please leave then below.

BrowserID and NSTIC

This post is in response to a tweet by @francesIDexpert who asked: “For those of you following #NSTIC, what do you think about this http://t.co/zUErAzZ”, where the shortened link refers to an article on BrowserID.

Here is my take on BrowserID and the Verified Email Protocol that it is based on. The functionality provided by an “IDBrowser Primary Authority” is equivalent to the functionality that would be provided by a certificate authority (CA) that would issue to a user a PKI certificate binding a public key to an email address, the CA being the email service providing the address.

I see two positives and one negative in BrowserID. The positives are:

  1. Having an email service provider issue email-address certificates, and
  2. Having the certificates issued automatically.

The negative is that BrowserID reinvents the wheel. There is no need for a new type of certificate, a new certificate store in the browser and a Javascript API for submitting certificates to a relying party, when an email address can be carried in an ordinarly PKI certificate, which a browser can store and present to a relying party as a TLS client certificate.

Now to NSTIC.

An explicit privacy goal of NSTIC is that colluding relying parties should not be able to use the user’s credentials to track the user. That is, two different relying parties should not be able to tell that the same user has logged in to both of them by comparing their login logs. Using an email address as an identifier is incompatible with this goal.

One could argue that relying parties need the user’s email address anyway. That’s true today, because email is often used to recover from forgotten passwords. But another goal of NSTIC is to provide alternatives to passwords. Without passwords, many relying parties will have no valid reason to ask for an email address. (And there will consequently be less spam.)

So an email-address certificate is a good way of demonstrating ownership of an email address to a relying party with a legitimate need to know the address. Actually, I will incorporate that idea into our proposed NSTIC architecture (with proper credit, of course) at the very next revision of the white paper. But an email address is not a good idea as a universal identifier for the Web.

Thoughts about NSTIC after NIST IDtrust Workshop

I’m back from participating in the NIST IDtrust workshop with Karen Lewison. This was the 10th in a series, but the first I’ve attended. I learned a lot. Presentations and panels can be found online at http://middleware.internet2.edu/idtrust/2011/program.html.

Jeremy Grant made a presentation on the National Strategy for Trusted Identities in Cyberspace (NSTIC). He said the President will make an announcement on April 15, and there will soon be workshops to solicit ideas from the private sector; we are looking forward to that. There was interesting follow up during the workshop. A participant from a financial institution told us in a private discussion that he doubted his institution would be able to delegate authentication to an external identity provider, due to security and liability concerns. Paul Donfried gave a talk about Verizon’s Universal Identity Services. Asked about the business model for providing identity services he said that the identity provider could charge the relying party for a high level of assurance. Elaine Newton, in one of her presentations, talked about NSTIC, and about the Multi-Factor Authentication Initiative.

In the long flight back to San Diego, Karen and I did some brainstorming about all this and we came up with three thoughts.

The first thought is that double redirection would help solve many of the technical challenges of NSTIC. By double redirection I mean the following: instead of the Relying Party (RP) relying on a certificate signed by an Identity or Attribute Provider (IAP) and submitted by the browser, the RP redirects the browser (via a 302 redirect or a form submission) to the IAP, which authenticates the user and redirects the browser back to the RP, passing a token or handle that the RP can use to obtain identity and attribute information from the IAP. Thus the RP relies on the IAP not only to provide credentials to the user, but also to verify credentials presented by the user.

This provides a lot of flexibility. Any RP can gain the high level of assurance provided by complex credentials (e.g. multi-factor authentication including one-time passwords or revocable biometrics) without having to implement verification procedures for those credentials. The user can control what attributes the IAP will disclose to the RP without having to juggle many attribute certificates. The RP can use multiple IAPs, providing different attributes, in the same transaction. And last but not least, Paul Donfried’s business model becomes possible, since the IAP is aware of the transaction.

There have been quite a few double redirection protocols: MS Passport (now Windows Live ID), SAML Browser SSP Profile, Shibboleth, OpenID, OAuth, etc. Some of them have serious security issues, but the PKAuth protocol that we presented in our poster provides strong security, without requiring the IAP and the RP to have prior knowledge of each other. PKAuth is designed for social login, so it has the potential to unify the goals of NSTIC with the requirements of social networks.

The second thought is to use what we could call “vacuous certificates”. By a vacuous certificate I mean a certificate that contains no information about the subject of the certificate. It contains only a public key and CA information, including revocation information. The CA that issues the certificate is not an identity provider, it is just, so-to-speak, a revocation provider. The user acquires a vacuous certificate, and registers it with any number of identity providers, which associate identity data or attributes with the certificate. In other words, the identity data and attributes are metadata external to the certificate, rather than data internal to the certificate.

This provides the obvious benefit that the user only needs to keep track of one private key and certificate. Also, no certificates need to be revoked and reissued when identity data or attributes change. And this also seems to solve the liability problem: the user can register the vacuous certificate with his or her bank, so that the bank can be the identity provider for its own transactions. In a transfer of funds between two banks, both banks would be identity providers for the same transaction.

The third thought goes back to double redirection. NSTIC emphasizes both security and privacy. For some transactions, the IAP must authenticate the RP, for security reasons. For other transactions, the IAP must not know the identity of the RP, for privacy reasons. Direct presentation of credentials by the browser to the RP ensures the latter; but it might be possible to enjoy the benefits of double redirection while keeping the RP anonymous. That would require an extension of the HTTP protocol to support a form of double redirection where the browser hides the identity of the initiator of the transaction (the RP).