Certificate-less authentication relying on the DNSSEC PKI

Certificate-less authentication relying on the DNSSEC PKI
Florian Maury <[email protected]>
HSC
April 25, 2012
Abstract
Nowadays, X.509 certificates are widely deployed as a method to authenticate TLS servers. But although those
can be used to authenticate clients and sign emails, this authenticating mechanism is rarely seen in use in large
environments. The cost of operating and maintaining such an infrastructure is often the cause of the lack of success
of this solution. It indeed requires in most case the creation of a certificate authority (along with CRLs and/or
OSCP services), which is expensive. The distribution and the installation of these certificates by end users might
be also complicated (unprivileged users. . . ).
This document introduces a new DDDS Application to convert email addresses into Fully Qualified Domain
Name (FQDN)s and a sample protocol that allows end users to generate their own X.509 certificates through Identity
Based Encryption (IBE) (that is based on their identity and their password), publish them in the DNS, and provide
to applications a way to retrieve these certificates. With them, third parties are then able to authenticate end users
with a classic Challenge/Response (C/R) protocol based on nonces cryptographic signatures.
1
A quick primer on involved technologies
1.1
Identity Based Encryption
IBE designates a manner of generating asymmetric cryptographic key-pairs, which are derived from the users’ identity and a
secret.
The p and q primes used to calculate an RSA modulus can, for instance, be generated thanks to a secure Pseudo-Random
Number Generator (PRNG) seeded with the HMAC of the user identifier with a master password.
These prime numbers are obtained through a deterministic algorithm, allowing anybody with the master password, and the
identity of someone (which is public) to re-generate the key-pair associated with that user.
1.2
DDDS
Dynamic Delegation Discovery Service (DDDS) is a standard protocol (RFC 3401, 3402 and 3403) from the IETF, which allows
lazy binding of strings to data. The binding is obtained by requesting a database (for instance the DNS) for key/value pairs.
With the DNS database, keys are FQDNs and values are NAPTR resource records.
NAPTR resource records, known as rules, are composed of a priority (a preference order of the rules to apply), a series of
flags (indicating whether the rule is ending the discovery or not), a service name (indicating a type of resource the requestor is
searching for), and a replacement rule. This replacement rule is either a constant domain name or a regular expression which
is applied to a string constant known as the Application Unique String (AUS) (which is user-supplied as the beginning of the
resolution process). The result of the replacement or the regular expression substitution is then either used as a new database
key to request more rules, or considered as the final data, following the flags of the last applied rule.
1.3
DANE
DNS-based Authentication of Named Entities (DANE) 1 is an Internet Draft of the IETF already submitted to the RFC Editor
for publication as a standard track RFC. It defines a new type of DNS resource records named TLSA. These resource records
allow the publication of information about the X.509 certificates used by the TLS servers of this domain. The different types
of TLSA resource records range from restriction of the allowed certificates (a specific Certificate Authority, a set of specific
certificates) to the publication of trust anchors for this domain or the publication of a set of self-signed certificates. Of course,
these resource records integrity must be secured with DNSSEC.
1 https://datatracker.ietf.org/wg/dane/
1
1.4
DNSSEC
DNSSEC is an extension to the DNS protocol. It allows the publication of cryptographic signatures of DNS resource records
sets and public keys. These can be verified by resolvers to ensure the authenticity of the received answers.
A world-wide PKI has been deployed through the signature of the DNS root and the use of a mechanism to secure delegations
over zone cuts. This mechanism consists in publishing DNSSEC-signed fingerprints of the public key matching the private key
that signed the zone resource records. These fingerprints are served by the parent zone DNS server.
2
The protocol description
In this protocol, the user universal identifier is his email address. This choice seems reasonable as email addresses are already
perceived as identifiers by most of the general public, lots of websites and most instant messengers.
This identifier is used (HMAC-ed) along with the user password to generate a key-pair (the actual PRNG and asymmetric
cryptographic algorithms associated to the key-pair are to be determined), via a standardized PRNG algorithm (to be determined). The public key is then embedded in a self-signed X.509 certificate. This certificate can then be published in the DNS
in a TLSA resource record (type 3 ("consider this certificate for this service"), selector 0 ("the content of the resource record is
the full certificate")). The location of this DNS resource record is left to the discretion of the system administrator.
When the end user tries to authenticate to a service, the server sends him a nonce. The end user sends back to the server
his identifier (his email address) and the signature of the nonce. The end user does not have to possess any kind of storage
medium to hold his private key: he just needs to input his password in a compatible software which will compute his private
key, like it already did when he first generated his key-pair.
When receiving these pieces of data, the server builds the AUS from the user email address and begins a DDDS resolution in
order to retrieve the public key associated to this email address. Once retrieved, the server just needs to verify the signature of
the nonce to authenticate or not the user.
Email address
+
+----------------+
+--------------->|
PRNG
|+--------> Key-pair
|
+----------------+
+
(1) Alice
Password +
|
publishes
|
her public
Private key <---+---> Public key +-+ key in the
| DNS
|
v
+--------+
+-->| DNS
|+-----+
|
+--------+
|
Alice
Bob
|
|
|
(2) Hi, I want to authenticate myself
|
| (7)
|
| +-----------------------------------------------------> |
| DDDS
|
|
(3) Here is a nonce
|
| resolution
|
| <-----------------------------------------------------+ |
| based
|
| +----+ "Insert your password" asked locally to end user |
| on user’s
|
|
(4)| Computes the key-pair, discards the public key
|
| email
|
| <----+ Returns the private key
|
| address
|
| +----+
|
|
|
|
(5)| Signs the nonce with the private key
|
|
|
| <----+
|
|
|
|
(6) Here is my email address and the signed nonce
|
|
(8)
|
| +-----------------------------------------------------> |
|
Here is |
|
|+------+
Alice’s |
|
|
public key |
|
|<--------------------------+
|
(9) Check nonce signature +----+ |
|
|
|
|
+----> |
| (10) Hi, Alice :)
|
| <-----------------------------------------------------+ |
2.1
Benefits and observations
• The password is kept secret: nobody can learn it by sniffing the network
2
• The C/R authentication based on nonce prevents replay attacks between Alice and Bob. Replay attacks between Bob
and the DNS are limited to the DNSSEC signature lifetime (which therefore should be both short and coherent with the
DNS zone refreshing policy).
• Bob do not need to store any password. He only needs (direct or indirect) DNS connectivity and to associate the email
address to a user account.
• Even with weak/common passwords, key collisions should be rare (if the hash algorithm has a good dispersion property
and the PRNG is also sufficiently unpredictable) and rainbow tables attacks are thwarted by the use of the identifier as
"salt" of the password.
• Once published this way, the certificate can also be used to encrypt or verify signature of S/MIME messages (by using
the sender email address in a DDDS resolution)
• The DDDS application (yet to be defined formally) this protocol relies on can be used to find other types of DNS resource
records (CERT, TXT (PKA), . . . ).
• Password changes are centralized. The revocation delay of certificates is limited to the TLSA resource record TTL (which
should be therefore short).
3
Work in progress
This document only scratches the surface of the protocol. The goal is to meet people interested in the project in order to found
an IETF working group.
The next steps are:
• Request the creation of an IETF working group if enough people are interested
• Formalize the protocol as an Internet Draft (more precisely, the type of key pairs, the PRNG algorithm, and the DDDS
application specifications (according to RFC 3403) have to be defined
• Develop an open-source DDDS resolution library (a key problem is the secure handling of potentially unsafe regular
expressions, fetched from the DNS)
3