diff --git a/draft-ymbk-lsvr-l3dl-signing.xml b/draft-ymbk-lsvr-l3dl-signing.xml index 3555065..a8e1e22 100644 --- a/draft-ymbk-lsvr-l3dl-signing.xml +++ b/draft-ymbk-lsvr-l3dl-signing.xml @@ -59,10 +59,11 @@ The Layer 3 Discovery and Liveness protocol OPEN PDU contains a - key 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. + 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. @@ -82,13 +83,13 @@
- The Layer 3 Discovery and Liveness protocol [old ref because new - draft not yet pushed] OPEN PDU - contains an algorithm specifier and a key 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 Layer 3 Discovery and Liveness protocol [old ref because + new draft not yet pushed] 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 @@ -101,11 +102,10 @@ Type. With the PKI-mechanism, an enrollment step is performed. The - public key and an identifier of the subject are 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. + 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 @@ -115,7 +115,7 @@ 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 from the same peer with the same Key Type. + subsequent PDUs in the session.
@@ -124,7 +124,7 @@ 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: @@ -134,8 +134,10 @@ Compose the PDU, with all fields including "Sig Type" and "Signature Length" set, but omitting the trailing - "Signature" field itself. This is the "message to be - signed" for purposes of the signature algorithm. + "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. @@ -165,7 +167,7 @@
-
+
The process for verifying an OPEN PDU is slightly different @@ -224,7 +226,7 @@
-
+
The process for verifying non-OPEN PDUs is slightly simpler, @@ -283,29 +285,100 @@ - Use of a PKI requires, at minimum, configuration of a trust - anchor and an End-Entity certificate corresponding to each peer - with which this l3dl instance is expected to establish sessions. - Optionally, a PKI MAY also allow configuration of zero or more - intermediate CA certificates and certificate revocation lists, - as needed to support an operator's preferred PKI architecture. - In general, however, we strongly recommend keeping the PKI as - simple as possible, because all of the configured PKI data must - be provided via out-of-band means, and will require maintenance. + 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. - + + 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 I3DL. 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. + + + +
@@ -319,7 +392,7 @@ is needed.
@@ -329,19 +402,22 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8 | Payload Length | New Key Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| New Key Length | ~ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ -~ New Key ... | Old Sig Type | +| New Key Length | New Key ... | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| | New Cert Length | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| New Certificate ... | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Old Sig Type | Old Signature Length | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +| Old Signature ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -| Old Signature Length | ~ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ -~ Old Signature ... | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- The New Key Type, New Key Length, and New Key fields declare the - replacement algorithm suite and key. + 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. @@ -363,10 +439,10 @@ 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. + 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.
@@ -387,7 +463,7 @@ the same as in the TOFU method. With the PKI-based method, automated device provisioning could - restrict which subsidiary certificates are allowed from which peers + 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.