What is Identity Registration Protocol (IRP)?

The existing certificate management protocols are limited for doing full automation of certificate management. These include SCEP (Simple Certificate Enrollment Protocol) and CMP (RFC 4210). Neither includes authentication, which causes problems in many deployment scenarios. SCEP is limited in terms of what kinds of certificates it can work with. CMP is overly complex (based on ASN.1), and rarely implemented in its complete form.

Lawrence Hughes created a new authenticated, but simple to implement (small footprint) certificate management protocol called Identity Registration Protocol (IRP). It is well suited to non-web automated certificate management. It is secured with TLS, and includes both Username/Password Authentication (UPA), for use before you get a certificate, and Strong Client Authentication (SCA) once you have gotten a certificate. It is implemented using XML messages over TLS. It has messages to do the following (among other things):

• do UPA authentication (if SCA is not available or fails) upload a Certificate Signing Request (CSR)
• obtain a list of certificates on the server
• upload or download a certificate
• obtain a list of PKCS12 files on the server
• upload or download a PKCS12 file
• obtain a list of users on the server
• upload or download user info for any user (including current IP addresses)

IRP was submitted to IANA (Internet Assigned Numbers Authority). Lars Eggerts (chair of the IRTF at the time) reviewed the design and approved it for a TCP port number (4604). This is like SMTP email being assigned port 25. This is not an endorsement, just a recognition that the protocol is viable, meets all requirements for a modern protocol (e.g. supports Explicit TLS), does something useful, and does not duplicate functionality in any existing RFC.

IRP is fully IPv6 compliant, and will run in an IPv4-only, dual stack or IPv6-only environment.

What is IPv6?

Internet Protocol version 6 (IPv6) is a generational updating of the IPv4 protocol. IPv6 was originally specified in RFC 1883, “Internet Protocol, Version 6 (IPv6) Specification”, December 1995. It is similar to IPv4, using many of the same concepts and similar data structures, but it is not backward compatible with IPv4. It can be deployed in parallel to IPv4, on a given node, and on the same network connections, with no interference between the two protocols (this is called “dual stack”).

The major difference from IPv4 is the increase in the IP address size (in bits) and number of available public addresses. A related another major difference is the absence of Network Address Translation (NAT), which is made possible by the larger address space. IPv4 addresses are 32 bits, with a theoretical maximum of 4.3 billion addresses. IPv6 addresses are 128 bits, with a theoretical maximum of 340 trillion, trillion, trillion addresses. If you represent the size of the IPv4 address space with a billiard ball, the IPv6 address space would be 63 times the size of the sun.

IRP allows any node to register its current IPv6 address so that the IRP server for your domain always contains the most recently registered IPv6 address for all nodes in that domain. So when Alice wants to connect to Bob, she can try the most recent address that worked, but if Bob is no longer there, she can obtain his current IPv6 address (and presence information) from his IRP server, and then connect to him directly to him there. She can easily locate his IRP server by asking DNS to resolve the SRV (Service Locator) record for IRP for his domain (e.g. protocol = tcp, service = irp). That returns the nodename, port number, priority and weight for one or more IRP servers for his domain (e.g. hostname ws4.hughesnet.org, port 4604, priority 10, weight 5). This allows scaling to the entire global Internet.

IRP Features:

Three main features of IRP are:

• a User Directory (including items needed to issue certificates, like the fields of a Subject Distinguished Name, and their IP addresses)
• ability to list, upload and download cryptographic objects (CSRs, certificates, PKCS12 files, etc)
• ability to interact with a Certificate Authority to automate certificate management tasks

There is currently no scheme for an application or device to securely register its IP addresses in DNS, with authentication. It is possible to do this with IRP. An IRP server can relay the registered addresses to a nearby authoritative DNS server securely. This allows any IPv6 compliant device to register its global address in DNS securely, so that any node (e.g. a phone) can register its current address (which might change depending on where it connects to the Internet) so that anyone can connect to it. This makes possible fully decentralized messaging.

Currently IRP is a proprietary protocol owned and controlled by Sixscape, much like SSL was owned and controlled by Netscape. At some point, to allow its further evolution and refinement, as well as widespread adoption, we will release it as an IETF open standard.