From 1f453a4934d3486b4f81a0a0fdc790b16c18d5e9 Mon Sep 17 00:00:00 2001 From: Randy Bush Date: Tue, 26 May 2020 10:14:19 -0700 Subject: [PATCH] publish -00 adopted by wg --- Makefile | 4 +- draft-ymbk-lsvr-l3dl-signing.txt | 504 ----------------------------- draft-ymbk-lsvr-l3dl-signing.xml | 530 ------------------------------- 3 files changed, 2 insertions(+), 1036 deletions(-) delete mode 100644 draft-ymbk-lsvr-l3dl-signing.txt delete mode 100644 draft-ymbk-lsvr-l3dl-signing.xml diff --git a/Makefile b/Makefile index 565ee7d..70da836 100644 --- a/Makefile +++ b/Makefile @@ -4,7 +4,7 @@ # # Your nroff document is called foo.txt. Change below as appropiate. -NAME=draft-ymbk-lsvr-l3dl-signing +NAME=draft-ietf-lsvr-l3dl-signing DEST=psg.com:public_html RSY=rsync --rsh ssh -v -a -l -H -p -t -x --delete @@ -16,4 +16,4 @@ rsy: $(RSY) $(NAME).txt $(DEST) clean: - rm -f *.html *.txt + rm -f *.html diff --git a/draft-ymbk-lsvr-l3dl-signing.txt b/draft-ymbk-lsvr-l3dl-signing.txt deleted file mode 100644 index 0dd3510..0000000 --- a/draft-ymbk-lsvr-l3dl-signing.txt +++ /dev/null @@ -1,504 +0,0 @@ - - - - -Network Working Group R. Bush -Internet-Draft Arrcus & IIJ -Intended status: Standards Track R. Austein -Expires: November 8, 2020 Arrcus - May 7, 2020 - - - Layer 3 Discovery and Liveness Signing - draft-ymbk-lsvr-l3dl-signing-01 - -Abstract - - The Layer 3 Discovery and Liveness protocol OPEN PDU may contain a - key and a certificate, which can be used to verify signatures on - subsequent PDUs. This document describes two mechanisms based on - digital signatures, one that is Trust On First Use (TOFU), and one - that uses certificates to provide authentication as well as session - integrity. - -Requirements Language - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and - "OPTIONAL" in this document are to be interpreted as described in - BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all - capitals, as shown here. - -Status of This Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at https://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on November 8, 2020. - - - - - - - - -Bush & Austein Expires November 8, 2020 [Page 1] - -Internet-Draft Layer 3 Discovery and Liveness Signing May 2020 - - -Copyright Notice - - Copyright (c) 2020 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (https://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. Trust On First Use Method . . . . . . . . . . . . . . . . . . 3 - 2.1. Signing a PDU . . . . . . . . . . . . . . . . . . . . . . 3 - 2.2. Verifying the OPEN PDU . . . . . . . . . . . . . . . . . 4 - 2.3. Verifying Other PDUs . . . . . . . . . . . . . . . . . . 4 - 3. Public Key Infrastructure Method . . . . . . . . . . . . . . 5 - 3.1. Signing OPEN PDU with PKI . . . . . . . . . . . . . . . . 5 - 3.2. Verifying OPEN PDU with PKI . . . . . . . . . . . . . . . 5 - 4. Local Policy . . . . . . . . . . . . . . . . . . . . . . . . 6 - 5. NEWKEY, Key Roll . . . . . . . . . . . . . . . . . . . . . . 6 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 - 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 - -1. Introduction - - This draft is being published without incorporating changes from an - excellent security review. This is being done so a couple of other - drafts can reference it. While all comments will, of course, be - appreciated, readers may want to wait for the -01 version. - - The Layer 3 Discovery and Liveness protocol [I-D.ietf-lsvr-l3dl] OPEN - PDU contains an algorithm specifier, a key, and a certificate, which - can be used to verify signatures on subsequent PDUs. This document - describes two methods of key generation and signing for use by L3DL, - Trust On First Use (TOFU) and a PKI-based mechanism to provide - authentication as well as session integrity. - - - - - -Bush & Austein Expires November 8, 2020 [Page 2] - -Internet-Draft Layer 3 Discovery and Liveness Signing May 2020 - - - The Key in the OPEN PDU SHOULD be the public key of an asymmetric key - pair. The sender signs with the private key, of course. The device - sending the OPEN may use one key for all links, a different key for - each link, or some aggregation(s) thereof. - - In the TOFU method the OPEN key is generated on the sending device, - believed without question by the receiver, and used to verify all - subsequent PDUs from the same sender with the same Key Type. - - With the PKI-mechanism, an enrollment step is performed. The public - key is put into a certificate [RFC5280], which is signed by the the - operational environment's trust anchor. In this way, the relying - party can be confident that the public key is under control of the - identified L3DL protocol entity. - - To the receiver verifying signatures on PDUs, the two methods are - indistinguishable; the key provided in the OPEN PDU is used to verify - the signatures of subsequent PDUs. The difference that PKI-based - keys may be verified against the trust anchor when the OPEN PDU is - received. - - In the PKI method the OPEN key MUST be verified against the trust - anchor for the operational domain. It is then used to verify all - subsequent PDUs in the session. - -2. Trust On First Use Method - - There are three parts to using a key: signing PDUs, verifying the - OPEN PDU, and verifying subsequent PDUs. - -2.1. Signing a PDU - - All signed PDUs are generated in the same way: - - o Compose the PDU, with all fields including "Sig Type" and - "Signature Length" set, but omitting the trailing "Signature" - field itself. The Certificate Length should be zero and the - Certificate field should be empty. This is the "message to be - signed" for purposes of the signature algorithm. - - o Generate the signature as specified for the chosen signature - suite, using the private member of the asymmetric key pair. In - general this will involve first hashing the "message to be signed" - then signing the hash, but the precise details may vary with the - specific algorithm. The result will be a sequence of octets, the - length of which MUST be equal to the setting of the "Signature - Length" field. - - - - -Bush & Austein Expires November 8, 2020 [Page 3] - -Internet-Draft Layer 3 Discovery and Liveness Signing May 2020 - - - o Construct the complete message by appending the signature octets - to the otherwise complete message composed above. - - In the case of the OPEN PDU, the message to be signed will include - the public member of the asymmetric keypair, but as far as the - signature algorithm is concerned that's just payload, no different - from any other PDU content. - -2.2. Verifying the OPEN PDU - - The process for verifying an OPEN PDU is slightly different from the - process for verifying other PDU types, because the OPEN PDU also - establishes the session key. - - o Verify that the PDU is syntactically correct, and extract the Auth - Type, Key, Sig Type, and Signature fields. - - o Verify that Auth Type and Sig Type refer to the same algorithm - suite, and that said algorithm suite is one that the - implementation understands. - - o Construct the "message to be verified" by truncating the PDU to - remove the Signature field (in practice this should not require - copying any data, just subtract the signature length from the PDU - length). - - o Verify the message constructed above against the public key using - the rules for the specific signature suite. - - o Record Auth Type and Key as this sessions's authentication type - and session key, for use in verifying subseuqent PDUs. - - If any of the above verification steps fail, generate an error using - error code 2 ("Authorization failure in OPEN"). - -2.3. Verifying Other PDUs - - The process for verifying non-OPEN PDUs is slightly simpler, but - follows the same basic pattern as for OPEN PDUs. - - o Verify that the PDU is syntactically correct, and extract the Sig - Type and Signature fields. - - o Verify that Sig Type refers to the same algorithm suite as the - Auth Type recorded during verification of the OPEN PDU. - - o Construct the "message to be verified" by truncating the PDU to - remove the Signature field. - - - -Bush & Austein Expires November 8, 2020 [Page 4] - -Internet-Draft Layer 3 Discovery and Liveness Signing May 2020 - - - o Verify the message constructed above against the recorded session - key using the rules for the specific signature suite. - - If any of the above verification steps fail, generate an error using - error code 3 ("Signature failure in PDU"). - -3. Public Key Infrastructure Method - - Using a PKI, [RFC5280], is almost the same as using TOFU, but with - one additional step: during verification of an OPEN PDU, after - extracting the Key field from the PDU but before attempting to use it - to verify the PDU's signature, the receiver MUST verify the received - key against the PKI to confirm that it's an authorized key. - - Generating an OPEN PDU using the PKI method requires a certificate, - which must be supplied via out of band configuration. The - certificate is a signature of the public key to be sent in the Key - field of the OPEN PDU, signed by the trust anchor private key. - - Verifying an OPEN PDU using the PKI method requires the public key of - the trust anchor, which the receiver uses to verify the certificate, - thereby demonstrating that the supplied is represents an authorized - L3DL speaker in this administrative domain. - - We use the term "certificate" here in the generic sense. These are - not X.509 certificates: X.509 is much more complicated than we need - for L3DL. The certificates used here are just signatures of one key - (the session key supplied in the Key field of the OPEN PDU) by - another key (the trust anchor). - -3.1. Signing OPEN PDU with PKI - - Generating and signing the OPEN PDU with the PKI method is almost the - same as in Section 2.1. The only difference is that the PKI method - MUST supply the appropriate certificate in the Certificate field. - - Note that the Auth Type field applies to both the Key and Certificate - fields. That is: the certificate uses the same certificate suite as - the session keys, L3DL does not support cross-algorithm-suite - certification. - -3.2. Verifying OPEN PDU with PKI - - Verifying the OPEN PDU with PKI is similar to verifying with TOFU as - described in Section 2.2, but includes one critical extra step: - - After extracting the Key field from the PDU but before verifying the - Signature, extract the Certificate field and verfiy that the - - - -Bush & Austein Expires November 8, 2020 [Page 5] - -Internet-Draft Layer 3 Discovery and Liveness Signing May 2020 - - - Certificate is a valid signature of the Key field, according to the - rules for the signature suite specified by Auth Type. If this step - fails, handle as in Section 2.2. - -4. Local Policy - - Whether to use TOFU, PKI, or no signatures at all is a matter of - local policy, to be decided by the operator. The useful policy - combinations for Key and Certificate are probably: - - o Not signing: sender need not sign, receiver does not check. - - o Require TOFU: sender MUST supply key and receiver MUST check, - certificate not needed and ignored if sent. - - o Allow TOFU: sender must supply key and receiver MUST check, - receiver SHOULD check certificate if supplyed by sender. - - o Require PKI: sender must supply key and certificate, receiver must - check both. - -5. NEWKEY, Key Roll - - Modern key management allows for agility in 'rolling' to a new key or - even algorithm in case of key expiry, key compromise, or merely - prudence. Declaring a new key with an L3DL OPEN PDU would cause - serious churn in topology as a new OPEN may cause a withdraw of - previously announced encapsulations. Therefore, a gentler rekeying - is needed. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type = 8 | Payload Length | New Key Type | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | New Key Length | New Key ... | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | New Cert Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | New Certificate ... | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Old Sig Type | Old Signature Length | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + - | Old Signature ... | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - - - -Bush & Austein Expires November 8, 2020 [Page 6] - -Internet-Draft Layer 3 Discovery and Liveness Signing May 2020 - - - The New Key Type, New Key Length, New Key, New Cert Length, and New - Certificate field declare the replacement algorithm suite, key, and - certificate. - - The NEWKEY PDU is signed using the current (soon to be old) algorithm - suite and key. - - The sender and the receiver should be cautious of algorithm suite - downgrade attacks. - - To avoid possible race conditions, the receiver SHOULD accept - signatures using either the new or old key for a configurable time - (default 30 seconds). This is intended to accommodate situations - such as senders with high peer out-degree and a single per-device - asymmetric key. - - If the sender does not receive an ACK in the normal window, including - retransmission, then the sender MAY choose to allow a session reset - by either issuing a new OPEN or by letting the receiver eventually - have a signature failure (error code 3) on a PDU. - - The rekeying operation changes the session key and algorithm suite - described in Section 2.3. The NEWKEY PDU itself is verified using - the old algorithm and session key, subsequent PDUs are verified with - the new algorithm and session key recorded after the NEWKEY PDU has - been accepted. - -6. Security Considerations - - The TOFU method requires a leap of faith to accept the key in the - OPEN PDU, as it can not be verified against any authority. Hence it - is jokingly referred to as Married On First Date. The assurance it - does provide is that subsequent signed PDUs are from the same peer. - And data integrity is a positive side effect of the signature - covering the payload. - - The PKI-based method offers assurance that the certificate, and hence - the keying material, provided in the OPEN PDU are authorized by a - central authority, e.g. the network's network security team. The - onward assurance of talking to the same peer and data integrity are - the same as in the TOFU method. - - With the PKI-based method, automated device provisioning could - restrict which certificates are allowed from which peers on a per - interface basis. This would complicate key rolls. Where one draws - the line between rigidity, flexibility, and security varies. - - - - - -Bush & Austein Expires November 8, 2020 [Page 7] - -Internet-Draft Layer 3 Discovery and Liveness Signing May 2020 - - - The REKEY PDU is open to abuse to create an algorithm suite downgrade - attack. - -7. IANA Considerations - - This document requests the IANA create a new entry in the L3DL PDU - Type registry as follows: - - PDU - Code PDU Name - ---- ------------------- - 8 NEWKEY - - This document requests the IANA add a registry entry for "TOFU - - Trust On First Use" to the L3DL-Signature-Type registry as follows: - - Number Name - ------ ------------------- - 1 TOFU - Trust On First Use - 2 PKI - -8. Acknowledgments - - The authors than Russ Housley for advice and review. - -9. Normative References - - [I-D.ietf-lsvr-l3dl] - Bush, R., Austein, R., and K. Patel, "Layer 3 Discovery - and Liveness", draft-ietf-lsvr-l3dl-03 (work in progress), - November 2019. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, - . - - [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., - Housley, R., and W. Polk, "Internet X.509 Public Key - Infrastructure Certificate and Certificate Revocation List - (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, - . - - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC - 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, - May 2017, . - - - - - -Bush & Austein Expires November 8, 2020 [Page 8] - -Internet-Draft Layer 3 Discovery and Liveness Signing May 2020 - - -Authors' Addresses - - Randy Bush - Arrcus & IIJ - 5147 Crystal Springs - Bainbridge Island, WA 98110 - United States of America - - Email: randy@psg.com - - - Rob Austein - Arrcus, Inc. - - Email: sra@hactrn.net - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Bush & Austein Expires November 8, 2020 [Page 9] diff --git a/draft-ymbk-lsvr-l3dl-signing.xml b/draft-ymbk-lsvr-l3dl-signing.xml deleted file mode 100644 index d88a782..0000000 --- a/draft-ymbk-lsvr-l3dl-signing.xml +++ /dev/null @@ -1,530 +0,0 @@ - - - - - - - - - - - - - - - - - - Layer 3 Discovery and Liveness Signing - - - Arrcus & IIJ -
- - 5147 Crystal Springs - Bainbridge Island - WA - 98110 - United States of America - - randy@psg.com -
- - - - - - Arrcus, Inc. -
- sra@hactrn.net -
- - - - - - - The Layer 3 Discovery and Liveness protocol OPEN PDU may contain - a key and a certificate, which can be used to verify signatures on - subsequent PDUs. This document describes two mechanisms based on - digital signatures, one that is Trust On First Use (TOFU), and one - that uses certificates to provide authentication as well as session - integrity. - - - - - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and - "OPTIONAL" in this document are to be interpreted as described in - BCP 14 when, - and only when, they appear in all capitals, as shown here. - - - - - - - -
- - This draft is being published without incorporating changes from - an excellent security review. This is being done so a couple of - other drafts can reference it. While all comments will, of course, - be appreciated, readers may want to wait for the -01 version. - - The Layer 3 Discovery and Liveness protocol OPEN PDU contains an algorithm - specifier, a key, and a certificate, which can be used to verify - signatures on subsequent PDUs. This document describes two methods - of key generation and signing for use by L3DL, Trust On First Use - (TOFU) and a PKI-based mechanism to provide authentication as well - as session integrity. - - The Key in the OPEN PDU SHOULD be the public key of an asymmetric - key pair. The sender signs with the private key, of course. The - device sending the OPEN may use one key for all links, a different - key for each link, or some aggregation(s) thereof. - - In the TOFU method the OPEN key is generated on the sending - device, believed without question by the receiver, and used to - verify all subsequent PDUs from the same sender with the same Key - Type. - - With the PKI-mechanism, an enrollment step is performed. The - public key is put into a certificate , which - is signed by the the operational environment's trust anchor. In - this way, the relying party can be confident that the public key is - under control of the identified L3DL protocol entity. - - To the receiver verifying signatures on PDUs, the two methods are - indistinguishable; the key provided in the OPEN PDU is used to - verify the signatures of subsequent PDUs. The difference that - PKI-based keys may be verified against the trust anchor when the - OPEN PDU is received. - - In the PKI method the OPEN key MUST be verified against the trust - anchor for the operational domain. It is then used to verify all - subsequent PDUs in the session. - -
- -
- - There are three parts to using a key: signing PDUs, verifying - the OPEN PDU, and verifying subsequent PDUs. - -
- - All signed PDUs are generated in the same way: - - - - - - Compose the PDU, with all fields including "Sig Type" and - "Signature Length" set, but omitting the trailing - "Signature" field itself. The Certificate Length should - be zero and the Certificate field should be empty. This - is the "message to be signed" for purposes of the - signature algorithm. - - - - Generate the signature as specified for the chosen signature - suite, using the private member of the asymmetric key pair. - In general this will involve first hashing the "message to - be signed" then signing the hash, but the precise details - may vary with the specific algorithm. The result will be a - sequence of octets, the length of which MUST be equal to the - setting of the "Signature Length" field. - - - - Construct the complete message by appending the signature - octets to the otherwise complete message composed above. - - - - - - - In the case of the OPEN PDU, the message to be signed will - include the public member of the asymmetric keypair, but as - far as the signature algorithm is concerned that's just - payload, no different from any other PDU content. - - -
- -
- - - The process for verifying an OPEN PDU is slightly different - from the process for verifying other PDU types, because the - OPEN PDU also establishes the session key. - - - - - - - Verify that the PDU is syntactically correct, and extract - the Auth Type, Key, Sig Type, and Signature fields. - - - - Verify that Auth Type and Sig Type refer to the same - algorithm suite, and that said algorithm suite is one that - the implementation understands. - - - - Construct the "message to be verified" by truncating the PDU - to remove the Signature field (in practice this should not - require copying any data, just subtract the signature length - from the PDU length). - - - - Verify the message constructed above against the public key - using the rules for the specific signature suite. - - - - Record Auth Type and Key as this sessions's authentication - type and session key, for use in verifying subseuqent PDUs. - - - - - - - If any of the above verification steps fail, generate an error - using error code 2 ("Authorization failure in OPEN"). - - - - -
- -
- - - The process for verifying non-OPEN PDUs is slightly simpler, - but follows the same basic pattern as for OPEN PDUs. - - - - - - - Verify that the PDU is syntactically correct, and extract - the Sig Type and Signature fields. - - - - Verify that Sig Type refers to the same algorithm suite as - the Auth Type recorded during verification of the OPEN PDU. - - - - Construct the "message to be verified" by truncating the PDU - to remove the Signature field. - - - - Verify the message constructed above against the recorded - session key using the rules for the specific signature - suite. - - - - - - - If any of the above verification steps fail, generate an error - using error code 3 ("Signature failure in PDU"). - - - - -
- -
- -
- - - Using a PKI, , is almost the same as using - TOFU, but with one additional step: during verification of an OPEN - PDU, after extracting the Key field from the PDU but before - attempting to use it to verify the PDU's signature, the receiver - MUST verify the received key against the PKI to confirm that it's - an authorized key. - - - - Generating an OPEN PDU using the PKI method requires a - certificate, which must be supplied via out of band - configuration. The certificate is a signature of the public key - to be sent in the Key field of the OPEN PDU, signed by the trust - anchor private key. - - - - Verifying an OPEN PDU using the PKI method requires the public - key of the trust anchor, which the receiver uses to verify the - certificate, thereby demonstrating that the supplied is - represents an authorized L3DL speaker in this administrative - domain. - - - - We use the term "certificate" here in the generic sense. These - are not X.509 certificates: X.509 is much more complicated than - we need for L3DL. The certificates used here are just - signatures of one key (the session key supplied in the Key field - of the OPEN PDU) by another key (the trust anchor). - - -
- - - Generating and signing the OPEN PDU with the PKI method is - almost the same as in . The - only difference is that the PKI method MUST supply the - appropriate certificate in the Certificate field. - - - - Note that the Auth Type field applies to both the Key and - Certificate fields. That is: the certificate uses the same - certificate suite as the session keys, L3DL does not support - cross-algorithm-suite certification. - - -
- -
- - - Verifying the OPEN PDU with PKI is similar to verifying with - TOFU as described in , but - includes one critical extra step: - - - - After extracting the Key field from the PDU but before - verifying the Signature, extract the Certificate field and - verfiy that the Certificate is a valid signature of the Key - field, according to the rules for the signature suite - specified by Auth Type. If this step fails, handle as in - . - - -
- -
- -
- - - Whether to use TOFU, PKI, or no signatures at all is a matter of - local policy, to be decided by the operator. The useful - policy combinations for Key and Certificate are probably: - - - - - - - Not signing: sender need not sign, receiver does not check. - - - - Require TOFU: sender MUST supply key and receiver MUST - check, certificate not needed and ignored if sent. - - - - Allow TOFU: sender must supply key and receiver MUST check, - receiver SHOULD check certificate if supplyed by sender. - - - - Require PKI: sender must supply key and certificate, - receiver must check both. - - - - - -
- -
- - Modern key management allows for agility in 'rolling' to a new - key or even algorithm in case of key expiry, key compromise, or - merely prudence. Declaring a new key with an L3DL OPEN PDU would - cause serious churn in topology as a new OPEN may cause a withdraw - of previously announced encapsulations. Therefore, a gentler - rekeying is needed. - - - -
- - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Type = 8 | Payload Length | New Key Type | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| New Key Length | New Key ... | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| | New Cert Length | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| New Certificate ... | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Old Sig Type | Old Signature Length | | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + -| Old Signature ... | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
- - The New Key Type, New Key Length, New Key, New Cert Length, and - New Certificate field declare the replacement algorithm suite, - key, and certificate. - - The NEWKEY PDU is signed using the current (soon to be old) - algorithm suite and key. - - The sender and the receiver should be cautious of algorithm suite - downgrade attacks. - - To avoid possible race conditions, the receiver SHOULD accept - signatures using either the new or old key for a configurable time - (default 30 seconds). This is intended to accommodate situations - such as senders with high peer out-degree and a single per-device - asymmetric key. - - If the sender does not receive an ACK in the normal window, - including retransmission, then the sender MAY choose to allow a - session reset by either issuing a new OPEN or by letting the - receiver eventually have a signature failure (error code 3) on a - PDU. - - - The rekeying operation changes the session key and algorithm - suite described in . The - NEWKEY PDU itself is verified using the old algorithm and - session key, subsequent PDUs are verified with the new algorithm - and session key recorded after the NEWKEY PDU has been accepted. - - -
- -
- - The TOFU method requires a leap of faith to accept the key in the - OPEN PDU, as it can not be verified against any authority. Hence it - is jokingly referred to as Married On First Date. The assurance it - does provide is that subsequent signed PDUs are from the same peer. - And data integrity is a positive side effect of the signature - covering the payload. - - The PKI-based method offers assurance that the certificate, and - hence the keying material, provided in the OPEN PDU are authorized - by a central authority, e.g. the network's network security team. The - onward assurance of talking to the same peer and data integrity are - the same as in the TOFU method. - - With the PKI-based method, automated device provisioning could - restrict which certificates are allowed from which peers - on a per interface basis. This would complicate key rolls. Where - one draws the line between rigidity, flexibility, and security - varies. - - The REKEY PDU is open to abuse to create an algorithm suite - downgrade attack. - -
- -
- - This document requests the IANA create a new entry in the L3DL PDU - Type registry as follows: -
- - PDU - Code PDU Name - ---- ------------------- - 8 NEWKEY - -
- - This document requests the IANA add a registry entry for "TOFU - - Trust On First Use" to the L3DL-Signature-Type registry as follows: -
- - Number Name - ------ ------------------- - 1 TOFU - Trust On First Use - 2 PKI - -
- -
- -
- - The authors than Russ Housley for advice and review. - -
- - - - - - - - - - - - - - - -