< draft-farinacci-lisp-ecdsa-auth-02.txt | draft-farinacci-lisp-ecdsa-auth-03.txt > | |||
---|---|---|---|---|
Network Working Group D. Farinacci | Network Working Group D. Farinacci | |||
Internet-Draft lispers.net | Internet-Draft lispers.net | |||
Intended status: Experimental E. Nordmark | Intended status: Experimental E. Nordmark | |||
Expires: October 21, 2018 Zededa | Expires: March 8, 2019 Zededa | |||
April 19, 2018 | September 4, 2018 | |||
LISP Control-Plane ECDSA Authentication and Authorization | LISP Control-Plane ECDSA Authentication and Authorization | |||
draft-farinacci-lisp-ecdsa-auth-02 | draft-farinacci-lisp-ecdsa-auth-03 | |||
Abstract | Abstract | |||
This draft describes how LISP control-plane messages can be | This draft describes how LISP control-plane messages can be | |||
individually authenticated and authorized without a a priori shared- | individually authenticated and authorized without a a priori shared- | |||
key configuration. Public-key cryptography is used with no new PKI | key configuration. Public-key cryptography is used with no new PKI | |||
infrastructure required. | infrastructure required. | |||
Status of This Memo | Status of This Memo | |||
skipping to change at page 1, line 34 ¶ | skipping to change at page 1, line 34 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on October 21, 2018. | This Internet-Draft will expire on March 8, 2019. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2018 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 | 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 | |||
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
4. Public-Key Hash . . . . . . . . . . . . . . . . . . . . . . . 6 | 4. Public-Key Hash . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
5. Hash-EID Mapping Entry . . . . . . . . . . . . . . . . . . . 6 | 5. Hash-EID Mapping Entry . . . . . . . . . . . . . . . . . . . 7 | |||
6. Hash-EID Structure . . . . . . . . . . . . . . . . . . . . . 7 | 6. Hash-EID Structure . . . . . . . . . . . . . . . . . . . . . 7 | |||
7. Keys and Signatures . . . . . . . . . . . . . . . . . . . . . 7 | 7. Keys and Signatures . . . . . . . . . . . . . . . . . . . . . 8 | |||
8. Signed Map-Register Encoding . . . . . . . . . . . . . . . . 8 | 8. Signed Map-Register Encoding . . . . . . . . . . . . . . . . 8 | |||
9. Signed Map-Request Encoding . . . . . . . . . . . . . . . . . 8 | 9. Signed Map-Request Encoding . . . . . . . . . . . . . . . . . 9 | |||
10. Other Uses . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 10. Signed Map-Notify Encoding . . . . . . . . . . . . . . . . . 10 | |||
11. EID Authorization . . . . . . . . . . . . . . . . . . . . . . 9 | 11. Other Uses . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | 12. EID Authorization . . . . . . . . . . . . . . . . . . . . . . 11 | |||
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | |||
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | |||
14.1. Normative References . . . . . . . . . . . . . . . . . . 10 | 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
14.2. Informative References . . . . . . . . . . . . . . . . . 11 | 15.1. Normative References . . . . . . . . . . . . . . . . . . 13 | |||
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 12 | 15.2. Informative References . . . . . . . . . . . . . . . . . 15 | |||
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 12 | Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15 | |||
B.1. Changes to draft-farinacci-lisp-ecdsa-auth-02.txt . . . . 12 | Appendix B. Document Change Log . . . . . . . . . . . . . . . . 16 | |||
B.2. Changes to draft-farinacci-lisp-ecdsa-auth-01.txt . . . . 12 | B.1. Changes to draft-farinacci-lisp-ecdsa-auth-03.txt . . . . 16 | |||
B.3. Changes to draft-farinacci-lisp-ecdsa-auth-00.txt . . . . 13 | B.2. Changes to draft-farinacci-lisp-ecdsa-auth-02.txt . . . . 16 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 | B.3. Changes to draft-farinacci-lisp-ecdsa-auth-01.txt . . . . 16 | |||
B.4. Changes to draft-farinacci-lisp-ecdsa-auth-00.txt . . . . 16 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 | ||||
1. Introduction | 1. Introduction | |||
The LISP architecture and protocols [RFC6830] introduces two new | The LISP architecture and protocols [RFC6830] introduces two new | |||
numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators | numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators | |||
(RLOCs) which provide an architecture to build overlays on top of the | (RLOCs) which provide an architecture to build overlays on top of the | |||
underlying Internet. Mapping EIDs to RLOC-sets is accomplished with | underlying Internet. Mapping EIDs to RLOC-sets is accomplished with | |||
a Mapping Database System. EIDs and RLOCs come in many forms than | a Mapping Database System. EIDs and RLOCs come in many forms than | |||
just IP addresses, using a general syntax that includes Address | just IP addresses, using a general syntax that includes Address | |||
Family Identifier (AFI) [RFC1700]. Not only IP addresses, but other | Family Identifier (AFI) [RFC1700]. Not only IP addresses, but other | |||
skipping to change at page 4, line 32 ¶ | skipping to change at page 4, line 42 ¶ | |||
Public-Key RLOC: is a JSON string that encodes a public-key as an | 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 | RLOC-record for a Hash-EID mapping entry. The format of the JSON | |||
string is '{ "public-key" : "<pubkey>" }'. | string is '{ "public-key" : "<pubkey>" }'. | |||
Control-Plane Signature: a Map-Request or Map-Register sender signs | Control-Plane Signature: a Map-Request or Map-Register sender signs | |||
the message with its private key. The format of the signature is | the message with its private key. The format of the signature is | |||
a JSON string that includes sender information and the signature | a JSON string that includes sender information and the signature | |||
value. The JSON string is included in Map-Request and Map- | value. The JSON string is included in Map-Request and Map- | |||
Register messages. | Register messages. | |||
Signature-EID: is a Crypto-EID used for a Control-Plane signature to | Signature-ID: is a Crypto-EID used for a Control-Plane signature to | |||
register or request any type of EID. The Signature-EID is | register or request any type of EID. The Signature-ID is included | |||
included with the JSON-encoded signature in Map-Request and Map- | with the JSON-encoded signature in Map-Request and Map-Register | |||
Register messages. | 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 | 3. Overview | |||
LISP already has several message authentication mechanisms. They can | LISP already has several message authentication mechanisms. They can | |||
be found in [I-D.ietf-lisp-rfc6833bis], [I-D.ietf-lisp-sec], and | be found in [I-D.ietf-lisp-rfc6833bis], [I-D.ietf-lisp-sec], and | |||
[RFC8061]. The mechanisms in this draft are providing a more | [RFC8061]. The mechanisms in this draft are providing a more | |||
granular level of authentication as well as a simpler way to manage | granular level of authentication as well as a simpler way to manage | |||
keys and passwords. | keys and passwords. | |||
A client of the mapping system can be authenticated using public-key | A client of the mapping system can be authenticated using public-key | |||
skipping to change at page 5, line 34 ¶ | skipping to change at page 6, line 20 ¶ | |||
client itself can register. | client itself can register. | |||
2. Anyone can lookup the Hash-EID mappings. These mappings are not | 2. Anyone can lookup the Hash-EID mappings. These mappings are not | |||
usually authenticated with the mechanisms in this draft but use | usually authenticated with the mechanisms in this draft but use | |||
the shared configured password mechanisms from | the shared configured password mechanisms from | |||
[I-D.ietf-lisp-rfc6833bis] that provide group level | [I-D.ietf-lisp-rfc6833bis] that provide group level | |||
authentication. | authentication. | |||
3. When a Crypto-EID, or any EID type, is registered to the mapping | 3. When a Crypto-EID, or any EID type, is registered to the mapping | |||
system, a signature is included in the Map-Register message. | system, a signature is included in the Map-Register message. | |||
When a non-Crypto-EID is registered a Signature-EID is also | When a non-Crypto-EID is registered a Signature-ID is also | |||
included in the Map-Register message. | included in the Map-Register message. | |||
4. The Map-Server processes the registration by constructing the | 4. The Map-Server processes the registration by constructing the | |||
Hash-EID from the registered Crypto-EID, looks up the Hash-EID in | Hash-EID from the registered Crypto-EID, looks up the Hash-EID in | |||
the mapping system, obtains the public-key from the RLOC-record | the mapping system, obtains the public-key from the RLOC-record | |||
and verifies the signature. If Hash-EID lookup fails or the | and verifies the signature. If Hash-EID lookup fails or the | |||
signature verification fails, the Map-Register is not accepted. | signature verification fails, the Map-Register is not accepted. | |||
5. When a Crypto-EID, or any EID type, is looked up in the mapping | 5. When a Crypto-EID, or any EID type, is looked up in the mapping | |||
system, a signature is included with a Signature-EID in the Map- | system, a signature is included with a Signature-ID in the Map- | |||
Request message. | Request message. | |||
6. The Map-Server processes the request for a Crypto-EID by | 6. The Map-Server processes the request for a Crypto-EID by | |||
constructing the Hash-EID from the Signature-EID included in the | constructing the Hash-EID from the Signature-ID included in the | |||
Map-Request. The signer-EID is a Crypto-EID that accompanies a | 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 | signature in the Map-Request. The Hash-EID is looked up in the | |||
mapping system, obtains the public-key from the RLOC-record and | mapping system, obtains the public-key from the RLOC-record and | |||
verifies the Map-Request signature. If the Hash-EID lookup fails | verifies the Map-Request signature. If the Hash-EID lookup fails | |||
or the signature verification fails, the Map-Request is not | or the signature verification fails, the Map-Request is not | |||
accepted and a Negative Map-Reply is sent back with an action of | accepted and a Negative Map-Reply is sent back with an action of | |||
"auth-failure". | "auth-failure". | |||
4. Public-Key Hash | 4. Public-Key Hash | |||
When a private/public key-pair is created for a node, its IPv6 EID is | When a private/public key-pair is created for a node, its IPv6 EID is | |||
skipping to change at page 8, line 11 ¶ | skipping to change at page 8, line 45 ¶ | |||
of LISP message sent. See Section 8 and Section 9 for each message | of LISP message sent. See Section 8 and Section 9 for each message | |||
type. The signature data is passed through a sha256 hash function | type. The signature data is passed through a sha256 hash function | |||
before it is signed or verified. | before it is signed or verified. | |||
8. Signed Map-Register Encoding | 8. Signed Map-Register Encoding | |||
When a ETR registers its Crypto-EID or any EID type to the mapping | When a ETR registers its Crypto-EID or any EID type to the mapping | |||
system, it builds a LISP Map-Register message. The mapping includes | system, it builds a LISP Map-Register message. The mapping includes | |||
an EID-record which encodes the Crypto-EID, or any EID type, and an | an EID-record which encodes the Crypto-EID, or any EID type, and an | |||
RLOC-set. One of the RLOC-records in the RLOC-set includes the the | RLOC-set. One of the RLOC-records in the RLOC-set includes the the | |||
ETR's signature and signature-EID. The RLOC-record is formatted with | ETR's signature and signature-ID. The RLOC-record is formatted with | |||
a LCAF JSON Type, in the following format: | a LCAF JSON Type, in the following format: | |||
{ "signature" : "<signature-base64>", "signature-eid" : "<signer-eid>" } | { "signature" : "<signature-base64>", "signature-id" : "<signer-id>" } | |||
Where <signature-base64> is a base64 [RFC4648] encoded string over | Where <signature-base64> is a base64 [RFC4648] encoded string over | |||
the following ascii [RFC0020] string signature data: | the following ascii [RFC0020] string signature data: | |||
[<iid>]<crypto-eid> | [<iid>]<crypto-eid> | |||
Where <iid> is the decimal value of the instance-ID the Crypto-EID is | Where <iid> is the decimal value of the instance-ID the Crypto-EID is | |||
registering to and the <crypto-eid> is in the form of [RFC3513] where | registering to and the <crypto-eid> is in the form of [RFC3513] where | |||
quad-nibbles between colons ARE NOT zero-filled. | quad-nibbles between colons ARE NOT zero-filled. | |||
skipping to change at page 8, line 41 ¶ | skipping to change at page 9, line 27 ¶ | |||
9. Signed Map-Request Encoding | 9. Signed Map-Request Encoding | |||
When an xTR (an ITR, PITR, or RTR), sends a Map-Request to the | When an xTR (an ITR, PITR, or RTR), sends a Map-Request to the | |||
mapping system to request the RLOC-set for a Crypto-EID, it signs the | mapping system to request the RLOC-set for a Crypto-EID, it signs the | |||
Map-Request so it can authenticate itself to the Map-Server the | Map-Request so it can authenticate itself to the Map-Server the | |||
Crypto-EID is registered to. The Map-Request target-EID field will | Crypto-EID is registered to. The Map-Request target-EID field will | |||
contain the Crypto-EID and the source-EID field will contain an LCAF | contain the Crypto-EID and the source-EID field will contain an LCAF | |||
JSON Type string with the following signature information: | JSON Type string with the following signature information: | |||
{ "source-eid" : "<seid>", "signature-eid" : "<signer-eid>", | { | |||
"signature" : "<signature-base64>" } | "source-eid" : "<seid>", | |||
"signature-id" : "<signer-id>", | ||||
"signature" : "<signature-base64>" | ||||
} | ||||
Where <signer-eid> is an IPv6 encoded string according to [RFC3513] | Where <signer-id> is an IPv6 encoded string according to [RFC3513] | |||
where quad-nibbles between colons ARE NOT zero-filled. The <seid> is | where quad-nibbles between colons ARE NOT zero-filled. The <seid> is | |||
the source EID from the data packet that is invoking the Map-Request | the source EID from the data packet that is invoking the Map-Request | |||
or the entire key/value pair for "source-eid" can be excluded when a | or the entire key/value pair for "source-eid" can be excluded when a | |||
data packet did not invoke the Map-Request (i.e. lig or an API | data packet did not invoke the Map-Request (i.e. lig or an API | |||
request). The <signer-eid> is the IPv6 Crypto-EID of the xTR that is | request). The <signer-id> is the IPv6 Crypto-EID of the xTR that is | |||
providing the Map-Request signature. | providing the Map-Request signature. | |||
The signature string <signature-base64> is a base64 [RFC4648] encoded | The signature string <signature-base64> is a base64 [RFC4648] encoded | |||
string over the following signature data: | string over the following signature data: | |||
<nonce><source-eid><crypto-eid> | <nonce><source-eid><crypto-eid> | |||
Where <nonce> is a hex string [RFC0020] of the nonce used in the Map- | Where <nonce> is a hex string [RFC0020] of the nonce used in the Map- | |||
Request and the <source-eid> and <crypto-eid> are hex strings | Request and the <source-eid> and <crypto-eid> are hex strings | |||
[RFC0020] of an IPv6 address in the form of [RFC3513] where quad- | [RFC0020] of an IPv6 address in the form of [RFC3513] where quad- | |||
nibbles between colons ARE NOT zero-filled. When <seid> is not | nibbles between colons ARE NOT zero-filled. When <seid> is not | |||
included in the Map-Request, string "0::0" is used for <source-eid>. | included in the Map-Request, string "0::0" is used for <source-eid>. | |||
10. Other Uses | 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. | ||||
11. Other Uses | ||||
The mechanisms described within this document can be used to sign | The mechanisms described within this document can be used to sign | |||
other types of LISP messages. And for further study is how to use | other types of LISP messages. And for further study is how to use | |||
these mechanisms to sign LISP encapsulated data packets in a | these mechanisms to sign LISP encapsulated data packets in a | |||
compressed manner to reduce data packet header overhead. | compressed manner to reduce data packet header overhead. | |||
In addition to authenticating other types of LISP messages, other | In addition to authenticating other types of LISP messages, other | |||
types of EID-records can be encoded as well and is not limited to | types of EID-records can be encoded as well and is not limited to | |||
IPv6 EIDs. It is possible for a LISP xTR to register and request non | IPv6 EIDs. It is possible for a LISP xTR to register and request non | |||
IPv6 EIDs but use IPv6 Crypto-EIDs for the sole purpose of signing | IPv6 EIDs but use IPv6 Crypto-EIDs for the sole purpose of signing | |||
skipping to change at page 9, line 44 ¶ | skipping to change at page 11, line 17 ¶ | |||
+-----------------------+------------------------------------+ | +-----------------------+------------------------------------+ | |||
| IPv4 address prefixes | [RFC1123] | | | IPv4 address prefixes | [RFC1123] | | |||
| | | | | | | | |||
| Distinguished-Names | [I-D.farinacci-lisp-name-encoding] | | | Distinguished-Names | [I-D.farinacci-lisp-name-encoding] | | |||
| | | | | | | | |||
| Geo-Coordinates | [I-D.farinacci-lisp-geo] | | | Geo-Coordinates | [I-D.farinacci-lisp-geo] | | |||
| | | | | | | | |||
| LCAF defined EIDs | [RFC8060] | | | LCAF defined EIDs | [RFC8060] | | |||
+-----------------------+------------------------------------+ | +-----------------------+------------------------------------+ | |||
11. EID Authorization | 12. EID Authorization | |||
When a Crypto-EID is being used for IPv6 communication, it is | 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 | 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 | generated from the key-pair provisioned for the owner. For other EID | |||
types that are not directly associated with signature keys, they must | types that are not directly associated with signature keys, they must | |||
be validated for use by the mapping system they are registered to. | be validated for use by the mapping system they are registered to. | |||
This policy information for the mapping system must be configured in | This policy information for the mapping system must be configured in | |||
the Map-Servers the EID owner registers to. | the Map-Servers the EID owner registers to or a signed authorization | |||
provided by a third-party entity. | ||||
12. Security Considerations | 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 | The mechanisms within this specification are intentionally using | |||
accepted practices and state of the art public-key cryptography. | accepted practices and state of the art public-key cryptography. | |||
Crypto-EIDs can be made private when control messages are encrypted, | Crypto-EIDs can be made private when control messages are encrypted, | |||
for instance, using [RFC8061]. | for instance, using [RFC8061]. | |||
The topological or physical location of a Crypto-EID is only | The topological or physical location of a Crypto-EID is only | |||
available to the other Crypto-EIDs that register in the same LISP | available to the other Crypto-EIDs that register in the same LISP | |||
Instance-ID and have their corresponding Hash-EIDs registered. | Instance-ID and have their corresponding Hash-EIDs registered. | |||
skipping to change at page 10, line 27 ¶ | skipping to change at page 13, line 27 ¶ | |||
This draft doesn't address reply attacks directly. If a man-in-the- | This draft doesn't address reply attacks directly. If a man-in-the- | |||
middle captures Map-Register messages, it could send such captured | middle captures Map-Register messages, it could send such captured | |||
packets at a later time which contains signatures of the source. In | packets at a later time which contains signatures of the source. In | |||
which case, the Map-Server verifies the signature as good and | which case, the Map-Server verifies the signature as good and | |||
interprets the contents to be valid where in fact the contents can | interprets the contents to be valid where in fact the contents can | |||
contain old mapping information. This problem can be solved by | contain old mapping information. This problem can be solved by | |||
encrypting the contents of Map-Registers using a third-party protocol | encrypting the contents of Map-Registers using a third-party protocol | |||
like DTLS [RFC6347] or LISP-Crypto [RFC8061] directly by | like DTLS [RFC6347] or LISP-Crypto [RFC8061] directly by | |||
encapsulating Map-Registers in LISP data packets (using port 4341). | encapsulating Map-Registers in LISP data packets (using port 4341). | |||
13. IANA Considerations | 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 [I-D.ietf-lisp-sec]. | ||||
14. IANA Considerations | ||||
Since there are no new packet formats introduced for the | Since there are no new packet formats introduced for the | |||
functionality in this specification, there are no specific requests | functionality in this specification, there are no specific requests | |||
for IANA. | for IANA. | |||
14. References | 15. References | |||
14.1. Normative References | 15.1. Normative References | |||
[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, | [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, | |||
RFC 20, DOI 10.17487/RFC0020, October 1969, | RFC 20, DOI 10.17487/RFC0020, October 1969, | |||
<https://www.rfc-editor.org/info/rfc20>. | <https://www.rfc-editor.org/info/rfc20>. | |||
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - | [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - | |||
Application and Support", STD 3, RFC 1123, | Application and Support", STD 3, RFC 1123, | |||
DOI 10.17487/RFC1123, October 1989, | DOI 10.17487/RFC1123, October 1989, | |||
<https://www.rfc-editor.org/info/rfc1123>. | <https://www.rfc-editor.org/info/rfc1123>. | |||
skipping to change at page 11, line 46 ¶ | skipping to change at page 15, line 5 ¶ | |||
[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical | [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical | |||
Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, | Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, | |||
February 2017, <https://www.rfc-editor.org/info/rfc8060>. | February 2017, <https://www.rfc-editor.org/info/rfc8060>. | |||
[RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol | [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol | |||
(LISP) Data-Plane Confidentiality", RFC 8061, | (LISP) Data-Plane Confidentiality", RFC 8061, | |||
DOI 10.17487/RFC8061, February 2017, | DOI 10.17487/RFC8061, February 2017, | |||
<https://www.rfc-editor.org/info/rfc8061>. | <https://www.rfc-editor.org/info/rfc8061>. | |||
14.2. Informative References | [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID | |||
Separation Protocol (LISP) Multicast", RFC 8378, | ||||
DOI 10.17487/RFC8378, May 2018, | ||||
<https://www.rfc-editor.org/info/rfc8378>. | ||||
15.2. Informative References | ||||
[AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY | [AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY | |||
NUMBERS http://www.iana.org/assignments/address-family- | NUMBERS http://www.iana.org/assignments/address-family- | |||
numbers/address-family-numbers.xhtml?, Febuary 2007. | numbers/address-family-numbers.xhtml?, February 2007. | |||
[I-D.farinacci-lisp-geo] | [I-D.farinacci-lisp-geo] | |||
Farinacci, D., "LISP Geo-Coordinate Use-Cases", draft- | Farinacci, D., "LISP Geo-Coordinate Use-Cases", draft- | |||
farinacci-lisp-geo-05 (work in progress), April 2018. | farinacci-lisp-geo-05 (work in progress), April 2018. | |||
[I-D.farinacci-lisp-name-encoding] | [I-D.farinacci-lisp-name-encoding] | |||
Farinacci, D., "LISP Distinguished Name Encoding", draft- | Farinacci, D., "LISP Distinguished Name Encoding", draft- | |||
farinacci-lisp-name-encoding-05 (work in progress), March | farinacci-lisp-name-encoding-05 (work in progress), March | |||
2018. | 2018. | |||
[I-D.ietf-lisp-pubsub] | ||||
Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., | ||||
Cabellos-Aparicio, A., Barkai, S., Farinacci, D., | ||||
Boucadair, M., Jacquenet, C., and S. Secci, "Publish/ | ||||
Subscribe Functionality for LISP", draft-ietf-lisp- | ||||
pubsub-00 (work in progress), April 2018. | ||||
[I-D.ietf-lisp-rfc6833bis] | [I-D.ietf-lisp-rfc6833bis] | |||
Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, | Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, | |||
"Locator/ID Separation Protocol (LISP) Control-Plane", | "Locator/ID Separation Protocol (LISP) Control-Plane", | |||
draft-ietf-lisp-rfc6833bis-10 (work in progress), March | draft-ietf-lisp-rfc6833bis-13 (work in progress), August | |||
2018. | 2018. | |||
[I-D.ietf-lisp-sec] | [I-D.ietf-lisp-sec] | |||
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. | Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. | |||
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-15 | Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-15 | |||
(work in progress), April 2018. | (work in progress), April 2018. | |||
[X9.62] American National Standards Institute, "Public Key | [X9.62] American National Standards Institute, "Public Key | |||
Cryptography for the Financial Services Industry: The | Cryptography for the Financial Services Industry: The | |||
Elliptic Curve Digital Signature Algorithm (ECDSA)", | Elliptic Curve Digital Signature Algorithm (ECDSA)", | |||
NIST ANSI X9.62-2005, November 2005. | NIST ANSI X9.62-2005, November 2005. | |||
Appendix A. Acknowledgments | Appendix A. Acknowledgments | |||
A special thanks goes to Sameer Merchant for his ideas and technical | A special thanks goes to Sameer Merchant and Colin Cantrell for their | |||
contributions to the ideas in this draft. | ideas and technical contributions to the ideas in this draft. | |||
Appendix B. Document Change Log | Appendix B. Document Change Log | |||
[RFC Editor: Please delete this section on publication as RFC.] | [RFC Editor: Please delete this section on publication as RFC.] | |||
B.1. Changes to draft-farinacci-lisp-ecdsa-auth-02.txt | B.1. Changes to draft-farinacci-lisp-ecdsa-auth-03.txt | |||
o Posted September 2018. | ||||
o Change all occurrences of signature-EID to signature-ID. | ||||
o Document how Map-Servers sign Map-Notify messages so they can be | ||||
verified by xTRs. | ||||
o Add multi-signatures to mappings so a 3rd-party can allow an | ||||
entity to register any type of EID. | ||||
B.2. Changes to draft-farinacci-lisp-ecdsa-auth-02.txt | ||||
o Draft posted April 2018. | o Draft posted April 2018. | |||
o Generalize text to allow Map-Reqeusting and Map-Registering for | o Generalize text to allow Map-Requesting and Map-Registering for | |||
any EID type with a proper signature-EID and signature encoded | any EID type with a proper signature-EID and signature encoded | |||
together. | together. | |||
B.2. Changes to draft-farinacci-lisp-ecdsa-auth-01.txt | B.3. Changes to draft-farinacci-lisp-ecdsa-auth-01.txt | |||
o Draft posted October 2017. | o Draft posted October 2017. | |||
o Make it more clear what values and format the EID hash is run | o Make it more clear what values and format the EID hash is run | |||
over. | over. | |||
o Update references to newer RFCs and Internet Drafts. | o Update references to newer RFCs and Internet Drafts. | |||
B.3. Changes to draft-farinacci-lisp-ecdsa-auth-00.txt | B.4. Changes to draft-farinacci-lisp-ecdsa-auth-00.txt | |||
o Initial draft posted July 2017. | o Initial draft posted July 2017. | |||
Authors' Addresses | Authors' Addresses | |||
Dino Farinacci | Dino Farinacci | |||
lispers.net | lispers.net | |||
San Jose, CA | San Jose, CA | |||
USA | USA | |||
End of changes. 32 change blocks. | ||||
51 lines changed or deleted | 190 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |