LISP Control-Plane ECDSA Authentication and Authorization

Abstract

This draft describes how LISP control-plane messages can be individually authenticated and authorized without a a priori shared-key configuration. Public-key cryptography is used with no new PKI infrastructure required.¶

1. Introduction

The LISP architecture and protocols [RFC9300] introduces two new numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators (RLOCs) which provide an architecture to build overlays on top of the underlying Internet. Mapping EIDs to RLOC-sets is accomplished with a Mapping Database System. EIDs and RLOCs come in many forms than just IP addresses, using a general syntax that includes Address Family Identifier (AFI) [RFC1700]. Not only IP addresses, but other addressing information have privacy requirements. Access to private information is granted only to those who are authorized and authenticated. Using asymmetric keying with public key cryptography enforces authentication for entities that read from and write to the mapping system. The proposal described in this document takes advantage of the latest in Elliptic Curve Cryptography.¶

In this proposal the EID is derived from a public key, and the corresponding private key is used to authenticate and authorize Map-Register messages. Thus only the owner of the corresponding private key can create and update mapping entries from the EID. Furthermore, the same approach is used to authenticate Map-Request messages. This in combination with the mapping database containing authorization information for Map-Requests is used to restrict which EIDs can lookup up the RLOCs for another EID.¶

This specification introduces how to use the Distinguished-Name AFI [AFI] and the [RFC8060] LCAF JSON Type to encode public keys and signatures in the LISP mapping database. The information in the mapping database is used to verify cryptographic signatures in LISP control-plane messages such as the Map-Request and Map-Register.¶

2. Definition of Terms

Crypto-EID:

is an IPv6 EID where part of the EID includes a hash value of a public-key. An IPv6 EID is a Crypto-EID when the Map-Server is configured with an Crypto-EID Prefix that matches the IPv6 EID.¶

Crypto-EID Hash Length:

is the number of low-order bits in a Crypto-EID which make up the hash of a public-key. The hash length is determined by the Map-Server when it is configured with a Crypto-EID Prefix.¶

Crypto-EID Prefix:

is a configuration parameter on the Map-Server that indicates which IPv6 EIDs are Crypto-EIDs and what is the Crypto-EID Hash Length for the IPv6 EID. This can be different for different LISP Instance-IDs.¶

Hash-EID:

is a distinguished name EID-record stored in the mapping database. The EID format is 'hash-<pubkey-hash>'. When a key-pair is generated for an endpoint, the produced private-key does not leave the xTR that will register the Crypto-EID. A hash of the public-key is used to produce a Crypto-EID and a Hash-EID. The Crypto-EID is assigned to the endpoint and the xTR that supports the LISP-site registers the Crypto-EID. Another entity registers the Hash-EID mapping with the public-key as an RLOC-record.¶

Public-Key RLOC:

is a JSON string that encodes a public-key as an RLOC-record for a Hash-EID mapping entry. The format of the JSON string is '{ "public-key" : "<pubkey>" }'.¶

Control-Plane Signature:

a Map-Request or Map-Register sender signs the message with its private key. The format of the signature is a JSON string that includes sender information and the signature value. The JSON string is included in Map-Request and Map-Register messages.¶

Signature-ID:

is a Crypto-EID used for a Control-Plane signature to register or request any type of EID. The Signature-ID is included with the JSON-encoded signature in Map-Request and Map-Register messages.¶

Multi-Signatures:

multiple signatures are used in LISP when an entity allows and authorized another entity to register an EID. There can be more than one authorizing entities that allow a registering entity to register an EID. The authorizing entities sign their own RLOC-records that are registered and merged into the registering entity's Hash-EID public-key mapping. And when the registering entity registers the EID, all authorizing entity signatures must be verified by the Map-Server before the EID is accepted.¶

3. Overview

LISP already has several message authentication mechanisms. They can be found in [RFC9301], [RFC9303], and [RFC8061]. The mechanisms in this draft are providing a more granular level of authentication as well as a simpler way to manage keys and passwords.¶

A client of the mapping system can be authenticated using public-key cryptography. The client is required to have a private/public key-pair where it uses the private-key to sign Map-Requests and Map-Registers. The server, or the LISP entity, that processes Map-Requests and Map-Registers uses the public-key to verify signatures.¶

The following describes how the mapping system is used to implement the public-key crypto system:¶

1. An entity registers Hash-EID to Public-Key RLOC mappings. A third-party entity that provides a service can register or the client itself can register.¶
2. Anyone can lookup the Hash-EID mappings. These mappings are not usually authenticated with the mechanisms in this draft but use the shared configured password mechanisms from [RFC9301] that provide group level authentication.¶
3. When a Crypto-EID, or any EID type, is registered to the mapping system, a signature is included in the Map-Register message. When a non-Crypto-EID is registered a Signature-ID is also included in the Map-Register message.¶
4. The Map-Server processes the registration by constructing the Hash-EID from the registered Crypto-EID, looks up the Hash-EID in the mapping system, obtains the public-key from the RLOC-record and verifies the signature. If Hash-EID lookup fails or the signature verification fails, the Map-Register is not accepted.¶
5. When a Crypto-EID, or any EID type, is looked up in the mapping system, a signature is included with a Signature-ID in the Map-Request message.¶
6. The Map-Server processes the request for a Crypto-EID by constructing the Hash-EID from the Signature-ID included in the Map-Request. The signer-ID is a Crypto-EID that accompanies a signature in the Map-Request. The Hash-EID is looked up in the mapping system, obtains the public-key from the RLOC-record and verifies the Map-Request signature. If the Hash-EID lookup fails or the signature verification fails, the Map-Request is not accepted and a Negative Map-Reply is sent back with an action of "auth-failure".¶

5. Hash-EID Mapping Entry

A Hash-EID is formatted in an EID-record as a Distinguished-Name AFI as specified in [I-D.ietf-lisp-name-encoding]. The format of the string is:¶

EID-record: 'hash-<hash-eid>'

Where <hash-eid> is a public-key hash as described in Section 4. The RLOC-record to encode and store the public-key is in LCAF JSON Type format of the form:¶

RLOC-record: '{ "public-key" : "<pubkey-base64>" }'

Where <pubkey-base64> is a base64 [RFC4648] encoding of the public-key generated for the system that is assigned the Hash-EID.¶

6. Hash-EID Structure

Since the Hash-EID is formatted as a distinguished-name AFI, the format of the <hash-eid> for EID 'hash-<hash-eid>' needs to be specified. The format will be an IPv6 address [RFC3513] where colons are used between quad-nibble characters when the hash bit length is a multiple of 4. And when the hash bit length is not a multiple of 4 but a multiple of 2, a leading 2 character nibble-pair is present. Here are some examples for different hash bit lengths:¶

Crypto-EID: 2001:5::1111:2222:3333:4444, hash length 64:
  Hash-EID is: 'hash-1111:2222:3333:4444'

Crypto-EID: 2001:5::11:22:33:44, hash length 64:
  Hash-EID is: 'hash-0011:0022:0033:0044'

Crypto-EID: 2001:5:aaaa:bbbb:1111:2222:3333:4444, hash length 80:
  Hash-EID is: 'hash-bbbb:1111:2222:3333:4444'

Crypto-EID: 2001:5:aaaa:bbbb:1111:2222:3333:4444, hash length 72:
  Hash-EID is: 'hash-bb:1111:2222:3333:4444'

Crypto-EID: 2001:5:aaaa:bbbb:1111:22:33:4444, hash length 72:
  Hash-EID is: 'hash-bb:1111:0022:0033:4444'

Note when leading zeroes exist in a IPv6 encoded quad between colons, the zeros are included in the quad for the Hash-EID string.¶

The entity that creates the hash, the entity that registers the Crypto-EID and the Map-Server that uses the hash for Hash-EID lookups MUST agree on the hash bit length.¶

7. Keys and Signatures

Key generation, message authentication with digital signatures, and signature verification will use the Elliptic Curve Digital Signature Algorithm or ECDSA [X9.62]. For key generation curve 'NIST256p' is used and recommended.¶

Signatures are computed over signature data that depends on the type of LISP message sent. See Section 8 and Section 9 for each message type. The signature data is passed through a sha256 hash function before it is signed or verified.¶

10. Signed Map-Notify Encoding

When a Map-Server originates a Map-Notify message either as an acknowledgment to a Map-Register message, as a solicited [I-D.ietf-lisp-pubsub] notification, or an unsolicited [RFC8378] notification, the receiver of the Map-Notify can verify the message is from an authenticated Map-Server.¶

An RLOC-record similar to the one used to sign Map-Register messages is used to sign the Map-Notify message:¶

{ "signature" : "<signature-base64>", "signature-id" : "<signer-id>" }

Where the "signature-id" is an IPv6 crypto-EID used by the Map-Server to sign the RLOC-record. The signature data and the encoding format of the signature is the same as for a Map-Register message. See details in Section 8.¶

A receiver of a Map-Notify message will lookup the signature-id in the mapping system to obtain a public-key to verify the signature. The Map-Notify is accepted only if the verification is successful.¶

12. EID Authorization

When a Crypto-EID is being used for IPv6 communication, it is implicit that the owner has the right to use the EID since it was generated from the key-pair provisioned for the owner. For other EID types that are not directly associated with signature keys, they must be validated for use by the mapping system they are registered to. This policy information for the mapping system must be configured in the Map-Servers the EID owner registers to or a signed authorization provided by a third-party entity.¶

To achieve signed authorization, an entity that allows another entity to register an EID, must authorize the registering entity. It does so by adding RLOC-records to the registering entity's Hash-EID public-key mapping. The format of the RLOC-record is a JSON encoded record as follows:¶

{
  "allow-eid" : "<eid>",
  "signature-id" : "<signer-id>",
  "signature" : "<signature-base64>"
}

The format of the <signer-id> and <signature-base64> values are the same as described in Section 8. The <eid> value is in the same string format as the signature data described in Section 8. For other non-IPv6 EID types, the conventions in [RFC8060] are used. In all cases, the string encoding format of instance-ID '[<iid>]' prepended is to the EID string.¶

This entry is added to the RLOC-set of the registering entity's Hash-EID 'hash-<hash>' registration. The authorizing entity does signs the Map-Register and sends it with merge-semantics. The Map-Server accepts the registration after the signature is verified and merges the RLOC-record into the existing RLOC-set. The 'signature' is optional and when not included means the authorizing entity has not yet allowed the registering entity to register the EID <eid>. Note multiple entities can register RLOC-records with the same <eid> meaning that signature verification for all of them is required before the Map-Server accepts the registration.¶

When the Map-Server receives a Map-Register for <eid>, it looks up 'hash-<hash>' EID in the mapping system. If not found, the Map-Register EID-record is not processed and the next EID-record is retrieved from the Map-Register message, if it exists. If the Hash-EID entry is found, the registering entity's signature is verified first. If the verification fails, the Map-Register EID-record is not accepted. Otherwise, a search for the RLOC-set is done to look for all matches of the EID being registered with <eid>, for those entries found, if any of them do not have a "signature" JSON item, the EID-record is not accepted. Otherwise, the signature-id is looked up in the mapping system to retrieve the public-key of the authorizing entity. If the verification is successful, then a lookup for the next RLOC-record signature-id is done. Only when all signature verifications are verified, the Map-Register EID-record is accepted.¶

The Map-Server should reject an RLOC-record with a signature-id that contains the Hash-EID of the entry disallowing a registering entity to self authorize itself.¶

Here is an example of a Hash-EID mapping stored in the mapping system:¶

EID-record: [1000]'hash-1111:2222:3333:4444', RLOC-Set (count is 4):

  RLOC-record: { "public-key" : "<pubkey-base64>" }
  RLOC-record: { "allow-eid" : "[1000]1.1.1.1/32",
                 "signature" : "<sig>",
                 "signature-id" : "[1000]2001:5:3::1111" }
  RLOC-record: { "allow-eid" : "[1000]1.1.1.1/32",
                 "signature" : "<sig>",
                 "signature-id" : "[1000]2001:5:3::2222" }
  RLOC-record: { "allow-eid" : "37-16-46-N-121-52-4-W",
                 "signature-id" : "[1000]2001:5:3::5555" }

This mapping stores the public-key of the registering entity with Hash-EID 1111:2222:3333:4444. The registering entry registered this RLOC-record. There are two authorizing entities, :1111 and :2222, who allow it to register IPv4 EID 1.1.1.1/32. They each registered their respective RLOC-records. And a third authorizing entity :5555 that registers an RLOC-record that has not yet authorized the registering entity to register Geo-Coordinate 37-16-46-N-121-52-4-W. Note the mapping and the signature-IDs are all within the context of instance-ID 1000.¶

13. Security Considerations

The mechanisms within this specification are intentionally using accepted practices and state of the art public-key cryptography.¶

Crypto-EIDs can be made private when control messages are encrypted, for instance, using [RFC8061].¶

The topological or physical location of a Crypto-EID is only available to the other Crypto-EIDs that register in the same LISP Instance-ID and have their corresponding Hash-EIDs registered.¶

This draft doesn't address reply attacks directly. If a man-in-the- middle captures Map-Register messages, it could send such captured packets at a later time which contains signatures of the source. In which case, the Map-Server verifies the signature as good and interprets the contents to be valid where in fact the contents can contain old mapping information. This problem can be solved by encrypting the contents of Map-Registers using a third-party protocol like DTLS [RFC6347] or LISP-Crypto [RFC8061] directly by encapsulating Map-Registers in LISP data packets (using port 4341).¶

Map-Reply message signatures and authentication are not in scope for this document. This document focuses on authentication between xTRs and mapping system components. Map-Reply authentication, which is performed between xTRs is described in [RFC9303].¶

14. IANA Considerations

Since there are no new packet formats introduced for the functionality in this specification, there are no specific requests for IANA.¶

15. References

Appendix A. Acknowledgments

A special thanks goes to Sameer Merchant and Colin Cantrell for their ideas and technical contributions to the ideas in this draft.¶

Appendix B. Document Change Log

[RFC Editor: Please delete this section on publication as RFC.]¶