< 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/