Router Keying for BGPsec
draft-ietf-sidrops-rtr-keying-06
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2019-07-12
|
06 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-06-24
|
06 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-06-06
|
06 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2019-05-17
|
06 | (System) | RFC Editor state changed to EDIT |
2019-05-17
|
06 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-05-17
|
06 | (System) | Announcement was received by RFC Editor |
2019-05-16
|
06 | (System) | IANA Action state changed to No IANA Actions from In Progress |
2019-05-16
|
06 | (System) | IANA Action state changed to In Progress |
2019-05-16
|
06 | Cindy Morgan | IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup |
2019-05-16
|
06 | Cindy Morgan | IESG has approved the document |
2019-05-16
|
06 | Cindy Morgan | Closed "Approve" ballot |
2019-05-16
|
06 | Cindy Morgan | Ballot approval text was generated |
2019-05-14
|
06 | Sean Turner | New version available: draft-ietf-sidrops-rtr-keying-06.txt |
2019-05-14
|
06 | (System) | New version approved |
2019-05-14
|
06 | (System) | Request for posting confirmation emailed to previous authors: Keyur Patel , Sean Turner , Randy Bush |
2019-05-14
|
06 | Sean Turner | Uploaded new revision |
2019-05-06
|
05 | Roman Danyliw | [Ballot comment] Thanks for making the updates in -04 and -05 to address ekr’s DISCUSSes. A few additional items: (1) Typos: ** Section 5.2.1. s/operators's/operators'/ … [Ballot comment] Thanks for making the updates in -04 and -05 to address ekr’s DISCUSSes. A few additional items: (1) Typos: ** Section 5.2.1. s/operators's/operators'/ ** Appendix B. s/pubic/public/ (2) Section 10 PKI-relying protocols, of which BGPsec is one, have many issues to consider - so many, in fact, entire books have been written to address them; so listing all PKI-related security considerations is neither useful nor helpful. It seems odd to say there is a large body of knowledge of relevant issues that won’t be discussed/cited/referenced here. (2) Appendix B. The n00b Guide to BGPsec Key Management It seems derogatory to refer to a section as being for “n00bs”. I would recommend alternative language. |
2019-05-06
|
05 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2019-04-11
|
05 | Sean Turner | New version available: draft-ietf-sidrops-rtr-keying-05.txt |
2019-04-11
|
05 | (System) | New version approved |
2019-04-11
|
05 | (System) | Request for posting confirmation emailed to previous authors: Keyur Patel , Sean Turner , Randy Bush |
2019-04-11
|
05 | Sean Turner | Uploaded new revision |
2019-03-05
|
04 | Alissa Cooper | [Ballot comment] Thank you for addressing my DISCUSS and COMMENT. |
2019-03-05
|
04 | Alissa Cooper | [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss |
2019-02-27
|
04 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-02-27
|
04 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2019-02-27
|
04 | Sean Turner | New version available: draft-ietf-sidrops-rtr-keying-04.txt |
2019-02-27
|
04 | (System) | New version approved |
2019-02-27
|
04 | (System) | Request for posting confirmation emailed to previous authors: Keyur Patel , Sean Turner , Randy Bush |
2019-02-27
|
04 | Sean Turner | Uploaded new revision |
2019-01-24
|
03 | Jean Mahoney | Closed request for Last Call review by GENART with state 'No Response' |
2019-01-24
|
03 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2019-01-24
|
03 | Martin Vigoureux | [Ballot comment] Hello, thank you for this Document. I only have a couple of questions: In the operator-generated method, the operator SHOULD extract the … [Ballot comment] Hello, thank you for this Document. I only have a couple of questions: In the operator-generated method, the operator SHOULD extract the certificate from the PKCS#7 certs-only message, and verify that the private key it holds corresponds to the returned public key. The router SHOULD extract the certificate from the PKCS#7 certs-only message and verify that the public key corresponds to the stored private key. I believe SHOULD applies to extract and to verify, correct? But I wonder why isn't that a MUST, or asked differently, what could happen wrong if that verification was not done? Thank you |
2019-01-24
|
03 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2019-01-24
|
03 | Ignas Bagdonas | [Ballot comment] A nit: s/NetConf/NETCONF |
2019-01-24
|
03 | Ignas Bagdonas | [Ballot Position Update] New position, Yes, has been recorded for Ignas Bagdonas |
2019-01-24
|
03 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-01-23
|
03 | Terry Manderson | [Ballot comment] [Authors/Shepherd need not respond these comments, these are just thoughts to take on as food for thought] Thank you for a concise document, … [Ballot comment] [Authors/Shepherd need not respond these comments, these are just thoughts to take on as food for thought] Thank you for a concise document, and especially thank you for the very informal appendix ("B") to explain BGPsec/PKI key management to people who are more concerned with making sure packets go from "here" to "there" and not be crypto key management experts. I have no strong concerns about document status, but BCP feels about right to me given the art of dealing with key material on routing kit is likely to evolve as experience dictates - that said, I won't be out of shape if the sponsoring AD and the rest of the IESG feels otherwise - however I see that BCP looks like the consensus at this stage. I'm torn about the absence of a clear recommendation to choose between a router-method operator-method. On one hand it seems a deficiency to leave it as "free to choose" without providing a set of considerations that may help direct the operators naive choice, and yet on the other hand the experience gained thus far appears limited and this BCP is yet to find its way, and may well be updated in future. |
2019-01-23
|
03 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2019-01-23
|
03 | Eric Rescorla | [Ballot discuss] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D13996 DETAIL S 2. > > Operators are free to use either the router-driven or … [Ballot discuss] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D13996 DETAIL S 2. > > Operators are free to use either the router-driven or operator-driven > method as supported by the platform. Regardless of the method > chosen, operators first establish a protected channel between the > management system and the router. How this protected channel is > established is router-specific and is beyond scope of this document. This seems rather under-specified. Given that we know that people are not careful about this, I think you need to specify some sort of minimum requirements for this channel. That need not be a particular protocol, but it needs to specify the security properties it provides. I see you have some SHOULD-level language later, but I think you need MUST level, and as noted below, I think the guidance is wrong. S 5.2. > the BGP Identifier when it sends the CSR to the CA. > > Even if the operator cannot extract the private key from the router, > this signature still provides a linkage between a private key and a > router. That is, the operator can verify the proof of possession > (POP), as required by [RFC6484]. It's not clear to me what is being claimed in terms of PoP here. As I understand it, the certificate is a binding between the AS number/BGP identifier pair and the public key, but if neither of those is in the PKCS#10 request, then they're not signed over by the private key, and so PoP isn't really operative. The relevant question is whether if I obtain the PKCS#10 request I can obtain a certificate for an identity other than the intended one. S 5.2.1. > ensure the returned private key did in fact come from the operator, > but this requires that the operator also provision via the CLI or > include in the SignedData the RPKI CA certificate and relevant > operator's EE certificate(s). The router should inform the operator > whether or not the signature validates to a trust anchor; this > notification mechanism is out of scope. I don't understand what security this is intended to provide. As I understand it, the way this works is that the operator signs the PKCS#8 package and then sends it to the router, which verifies the signature. This verification is performed based on a key configured by the operator, right? But in that case, if someone obtains operator access to the router, they can just configure their own key, thus bypassing the signature check. Secondarily, I don't understand how this works if the RPKI CA certificate is included in the SignedData, because then how do I validate it against a trust anchor. Finally, how does the router know which of the large number of EEs signed by the RPKI CA it should accept signed PKCS#8 messages from. S 6. > private key it holds corresponds to the returned public key. If the > operator saved the PKCS#10 it can check this correspondence by > comparing the public key in the CSR to the public key in the returned > certificate. If the operator has not saved the PKCS#10, it can check > this correspondence by generating a signature on any data and then > verifying the signature using the returned certificate. It is not clear to me that this is correct. You seem to be assuming that it given a key pair (K_priv, K_pub), it is not possible to generate a new key K_pub' that will validate signatures made with K_priv. This isn't ordinarily an assumption we make of digital signature systems. S 8. > the CA prior to operator initiating the router's CSR. CAs use > authentication material to determine whether the router is > eligible to receive a certificate. Authentication material at a > minimum includes the router's AS number and BGP Identifier as > well as the router's key material, but can also include > additional information. Authentication material can be Surely it also includes some information that allows the router to prove it is entitled to a key with that AS and BGP identifier, but I'm not seeing this here. S 12.1. > CSR you sent; the certificate will include the subject name, serial > number, public key, and other fields as well as being signed by the > CA. After the CA issues the certificate, the CA returns the > certificate, and posts the certificate to the RPKI repository. Check > that the certificate corresponds to the private key by verifying the > signature on the CSR sent to the CA; this is just a check to make This is not the right check. The CSR contains the public key. If you want to check, make sure it is identical to the one in the cert. |
2019-01-23
|
03 | Eric Rescorla | [Ballot comment] S 1. > These two methods differ in where the keys are generated: on the > router in the … [Ballot comment] S 1. > These two methods differ in where the keys are generated: on the > router in the router-driven method, and elsewhere in the > operator-driven method. Routers are required to support at least one > of the methods in order to work in various deployment environments. > Some routers may not allow the private key to be off-loaded while > others may. While off-loading private keys would ease swapping of Nit: "off-load" has multiple meanings. I would suggest "exported" S 1. > operator-driven method. Routers are required to support at least one > of the methods in order to work in various deployment environments. > Some routers may not allow the private key to be off-loaded while > others may. While off-loading private keys would ease swapping of > routing engines, exposure of private keys is a well known security > risk. This is a somewhat shallow treatment of this. Specifically: 1. There are multiple ways in which a device might allow a key not to be exported. For instance, there might not be a command, but it might be in unencrypted NVRAM. Or, it might be in an HSM. These have very different security properties. 2. There are designs which allow a key to be moved from device to device without exposure, e.g.,, a hardware token. S 1. > In the router-driven method, the router generates its own > public/private key-pair. > > The router-driven method mirrors the model used by traditional PKI > subscribers; the private key never leaves trusted storage (e.g., > Hardware Security Module). This is by design and supports classic This seems overly concrete. The router may or may not have an HSM, but there are benefits even if it does not. S 1. > ensure that no one can impersonate the subscriber. For non-humans, > this method does not always work. For example, when an operator > wants to support hot-swappable routers, the same private key needs to > be installed in the soon-to-be online router that was used by the the > soon-to-be offline router. This motivated the operator-driven > method. I'm not following this explanation, as it's routine for Internet servers to have keys in software and be able to transfer them from device to device. This is, after all, what PEM files do S 1. > acting as the intermediary. Section 8 describes another method that > requires more capable routers. > > Useful References: [RFC8205] describes gritty details, [RFC8209] > specifies the format for the PKCS#10 certification request, and > [RFC8208] specifies the algorithms used to generate the PKCS#10's Nit "The PKCS#10's signature" is not grammatical S 2. > method as supported by the platform. Regardless of the method > chosen, operators first establish a protected channel between the > management system and the router. How this protected channel is > established is router-specific and is beyond scope of this document. > Though other configuration mechanisms might be used, e.g. NetConf > (see [RFC6470]), the protected the protected channel between the "the protected the protected" S 3. > bis] to return the issued certificate, > > - Using FTP or HTTP per [RFC2585], and > > - Using Enrollment over Secure Transport (EST) protocol per > [RFC7030]. I'm surprised you don't list ACME. S 5. > is sometimes referred to as a Certificate Signing Request (CSR), may > be generated by the router or by the operator. > > The PKCS#10 request SHOULD be saved to enable verifying that the > returned public key in the certificate corresponds to the private > used to generate the signature on the CSR. This is generally not necessary. In most systems, the private key syntax either includes the public key or the public key can be generated from the private key. S 5.1. > > NOTE: If a router were to communicate directly with a CA to have the > CA certify the PKCS#10 certification request, there would be no way > for the CA to authenticate the router. As the operator knows the > authenticity of the router, the operator mediates the communication > with the CA. This doesn't seem like it's necessarily true. For instance, with ACME the operator could provide the router with a credential sufficient to authenticate the request. S 5.2.1. > > 5.2.1. Using PKCS#8 to Transfer Private Key > > A private key can be encapsulated in a PKCS#8 Asymmetric Key Package > > [RFC5958] and should be further encapsulated in Cryptographic Message SHOULD? S 10. > Private key protection in transit: Mistakes here are, for all, > practical purposes catastrophic because disclosure of the private > key allows another entity to masquerade as (i.e., impersonate) the > signer; transport security is therefore strongly RECOMMENDED. The > level of security provided by the transport layer's security > mechanism SHOULD be commensurate with the strength of the BGPsec I'm not sure "commensurate" is what's needed here. For instance, the transport channel might be much more secure than the router key (e.g., P-521 and AES-256 with a RSA-2048 router key). More generally, it's not clear to me that these are really connected at all, as the threat environments are totally different. As noted above, I believe you should just specify a minimal level. S 12.1. > and integrity and replay protection. > > Appendix B. The n00b Guide to BGPsec Key Management > > This appendix is informative. It attempts to explain all of the PKI > technobabble in plainer language. All fields have jargon, but generally deriding another field's language as "technobabble" doesn't seem that helpful. S 12.1. > BGPsec speakers send signed BGPsec updates that are verified by other > BGPsec speakers. In PKI parlance, the senders are referred to as > signers and the receivers are referred to as relying parties. The > signers with which we are concerned here are routers signing BGPsec > updates. Signers use private keys to sign and relying parties use > the corresponding public keys, in the form of X.509 public key They're not in the form of public key certificates, they are carried in certificates. S 12.1. > that will generate the key pair for the algorithms referenced in the > main body of this document; consult your router's documentation for > the specific commands. The key generation process will yield > multiple files: the private key and the public key; the file format > varies depending on the arcane command you issued, but generally the > files are DER or PEM-encoded. Actually, it may or may not generate multiple files. That's implementation specific. |
2019-01-23
|
03 | Eric Rescorla | [Ballot Position Update] New position, Discuss, has been recorded for Eric Rescorla |
2019-01-23
|
03 | Deborah Brungard | [Ballot comment] I agree with the status as BCP. It is describing current practices. On some other comments: I like having both approaches in the … [Ballot comment] I agree with the status as BCP. It is describing current practices. On some other comments: I like having both approaches in the same document vs. two different BCPs. I don't see the need to say "which is better" (Alvaro's comment). The document is quite clear on the different uses. It is dependent on much more than what is described here. And as section 8 says, it is becoming blurred. I think Appendix A is fine as separate from the main document. As section 2 says it is outside the scope. I liked Appendix B - Thanks! It's not so scary - especially with good automation tools. |
2019-01-23
|
03 | Deborah Brungard | [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard |
2019-01-23
|
03 | Alissa Cooper | [Ballot discuss] As this is a BCP, I don't understand why transport encryption of the private key is not normatively required. Could you explain? |
2019-01-23
|
03 | Alissa Cooper | [Ballot comment] Given that this document is ostensibly specifying a "best" current practice, I would have expected a clearer expression of preference for the router-driven … [Ballot comment] Given that this document is ostensibly specifying a "best" current practice, I would have expected a clearer expression of preference for the router-driven method over the operator-driven method, e.g., something like BGPsec-speaking routers MUST implement the router-driven method and MAY implement the operator-driven method. Or if there is some exception case that makes that MUST problematic, it would at least be good to emphasize which one of these is actually "best" from a security perspective, even though the other one is being specified and we know will be used. Nit in Section 1: s/gritty details/details of the BGPsec protocol/ |
2019-01-23
|
03 | Alissa Cooper | [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper |
2019-01-23
|
03 | Alvaro Retana | [Ballot comment] (1) I don't really have a strong objection for this document being a BCP. However, while documenting two different methods, there is no … [Ballot comment] (1) I don't really have a strong objection for this document being a BCP. However, while documenting two different methods, there is no clear indication of "what is believed to be the best" [rfc2026], or even better, which method should be used in what situations. I understand that operators have different preferences/needs and that prescribing one method as the default in not the right thing to do. I would really like to see some text (maybe a "Deployment Considerations" section) that talks about when one or the other might be preferred/considered. (2) §4: s/BGP Identifier [RFC4271]/BGP Identifier [RFC6286] (3) §4: "In the case where the operator has chosen not to use unique per-router certificates, a BGP Identifier of 0 MAY be used." rfc6286 defines the BGP Identifier as always being non-zero. rfc8209 says that "if the same certificate is issued to more than one router (and hence the private key is shared among these routers), the choice of the router ID used in this name is at the discretion of the Issuer." It seems to me that it doesn't matter which ID is used...it just can't be 0. The simple fix is to just remove the sentence. (4) §8: "Enabling the router-to-CA connectivity MAY require connections to external networks (i.e., through firewalls, NATs, etc.)." That "MAY" is out of place because this sentence is just stating a fact. (5) §8: "Note that the checks performed by the router in Section 7...SHOULD be performed." Besides confirming the checks from §7, I'm not sure what this sentence really contributes...but I do think that the "SHOULD" is out of place because the Normative language is already in §7. (6) Nits s/used by the the/used by the s/corresponds to the private used/corresponds to the private key used |
2019-01-23
|
03 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2019-01-22
|
03 | Adam Roach | [Ballot comment] Thanks to the authors for a well-written and clear document. I have one substantive comment, and a minor editorial nit. --------------------------------------------------------------------------- §3: > … [Ballot comment] Thanks to the authors for a well-written and clear document. I have one substantive comment, and a minor editorial nit. --------------------------------------------------------------------------- §3: > - Using FTP or HTTP per [RFC2585], and It's not clear from a casual examination whether use of unencrypted and non-integrity-protected channels for these operations are safe. I would expect to see a discussion of this in this section and/or section 10. The closest I could find is the SHOULD-strength (!) recommendation for transport-level security for private key transport. Without a more thorough analysis, I suspect we should more strongly deprecate the use of unencrypted/non-integrity-protected transports. This document is, after all, supposed to be calling out best practice; and, in 2019, that really does entail transport security except under the most exceptional circumstances. --------------------------------------------------------------------------- §2: > Though other configuration mechanisms might be used, e.g. NetConf > (see [RFC6470]), the protected the protected channel between the Nit: duplicate "...the protected..." |
2019-01-22
|
03 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2019-01-22
|
03 | Ben Campbell | [Ballot comment] - General: The document says it's intended as BCP, but the data tracker says "Proposed Standard". Was this last called with the correct … [Ballot comment] - General: The document says it's intended as BCP, but the data tracker says "Proposed Standard". Was this last called with the correct status? (I agree with BCP, by the way.) - I share Benjamin's concern about the idea of moving private keys between routers as a "need" vs "something people do". §5.2.1: "The router should inform the operator whether or not the signature validates to a trust anchor; this notification mechanism is out of scope." Should that be normative? §9.3: The second paragraph is a single convoluted sentence. Can it be broken into simpler sentences? §10: - "This document defines no protocols. So, in some sense, it introduces no new security considerations." I think practices can absolutely come with security considerations. For example, the practice of moving private keys between routers. - "Private key protection in transit": Is there no expectations that transmitted private keys would have object-level encryption? §A: I'm curious why this is not part of the main-body security considerations? |
2019-01-22
|
03 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2019-01-22
|
03 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2019-01-22
|
03 | Alexey Melnikov | [Ballot comment] No strong opinion on document status. |
2019-01-22
|
03 | Alexey Melnikov | [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov |
2019-01-21
|
03 | Warren Kumari | Already on Telechat, just updating Datatracker |
2019-01-21
|
03 | Warren Kumari | IESG state changed to IESG Evaluation from Waiting for Writeup |
2019-01-21
|
03 | Benjamin Kaduk | [Ballot comment] I know the intended status has been beaten to near death already, but I could see this as Informational as well as BCP. … [Ballot comment] I know the intended status has been beaten to near death already, but I could see this as Informational as well as BCP. Section 1 For example, when an operator wants to support hot-swappable routers, the same private key needs to be installed in the soon-to-be online router that was used by the the soon-to-be offline router. This motivated the operator-driven method As the secdir review notes, there is no need to copy private keys to hot-swap routers (unless there is something special about the "hot-swap" case that nullifies the arguments he made?). It rather seems that we should avoid framing this behavior as justified by a need for hot-swapping, but rather as something that people do to work around processes that do not admit the more secure workflow, as an operational reality. Section 2 (see [RFC6470]), the protected the protected channel between the nit: duplicate "the protected" Section 5 The PKCS#10 request SHOULD be saved to enable verifying that the returned public key in the certificate corresponds to the private used to generate the signature on the CSR. I mostly assume this is done by the party that generates the CSR, though perhaps one could read it as being done on the router always. (I guess later on we do recommend both the operator and router to do this verification.) This could be reworded, though, either to remove the 2119 language ("Retaining the CSR allows for verifying that [...]" or to apply to the actual verification as opposed to just the saving. Section 5.1 NOTE: If a router were to communicate directly with a CA to have the CA certify the PKCS#10 certification request, there would be no way for the CA to authenticate the router. As the operator knows the authenticity of the router, the operator mediates the communication with the CA. nit: I think that the thing we care about here is the CA's ability to show that the request is authorized. The operator is assumed to have an account/relationship with the CA and a channel via which to authorize cert-signing requests. In particular, "no way" is a rather strong statement, and would seem to deny the possibility of a three-party workflow where the router sends the CSR to the CA but the operator logs in to the CA independently and is presented with a list of pending requests to approve. (It would also preclude the operator from delegating their authorization at the CA to the router, as described in Section 8.) Section 5.2 ("Operator-Generated Keys") Even if the operator cannot extract the private key from the router, this signature still provides a linkage between a private key and a router. That is, the operator can verify the proof of possession (POP), as required by [RFC6484]. This paragraph seems a bit of a non-sequitur -- if the operator just generated the key, it sure isn't going to need to extract the private key from the router to sign something using it! Section 6 In the operator-generated method, the operator SHOULD extract the certificate from the PKCS#7 certs-only message, and verify that the private key it holds corresponds to the returned public key. If the nit: "private key it holds" is the one the operator holds, not the PKCS#7 certs-only message. It's probably worth disambiguating, here. Section 7 NOTE: The signature on the PKCS#8 and Certificate need not be made by the same entity. Signing the PKCS#8 permits more advanced configurations where the entity that generates the keys is not the direct CA. Why are we talking about PKCS#8 (asymmetric key transport) signatures here at all? This is the section about installing certificates! I guess I am not terribly familiar with the RPKI, but in the Web PKI at least it's quite uncommon for the CA to be generating the private keys, so mentioning these together is a non sequitur to me. Section 8 More PKI-capable routers can take advantage of this increased functionality and lighten the operator's burden. Typically, these nit: most readers will not bind "this" to the right thing and will instead be left confused. Why do we not mention the need to get the manufacturer-installed key material (or information thereof) to the operator? When a router is so configured, the communication with the CA SHOULD be automatically re-established by the router at future times to renew or rekey the certificate automatically when necessary (See Section 9). This further reduces the tasks required of the operator. Mentioning renewing certificates is natural, as they have a stated end time to prepare for. Re-keying certificates is something of a different matter, and it would be nice to provide (a link to) some guidance on what timescales at which to rekey, if we're mentioning rekeying here. (draft-ietf-sidrops-bgpwec-rollover provides some related guidance, but I did not see much concrete on this point.) Section 9.4 Currently routers often generate private keys for uses such as SSH, and the private keys may not be seen or off-loaded from the router. While this is good security, it creates difficulties when a routing engine or whole router must be replaced in the field and all software which accesses the router must be updated with the new keys. Also, This seems to be talking about key management for keys other than BGPsec-signing keys. Isn't that out of scope for this document? any network based initial contact with a new routing engine requires trust in the public key presented on first contact. To allow operators to quickly replace routers without requiring update and distribution of the corresponding public keys in the RPKI, routers SHOULD allow the private BGPsec key to be inserted via a Making this a SHOULD is perhaps an overstatement, since AFAICT this functionality is not useful for the stated purpose unless the operator has access to private keys directly (whether by virtue of the operator having generated the keys or an extraction interface on the current routers). This is an inherent tradeoff, as stated, between the delay in update/distribution of public keys in the RPKI vs. reducing the risk of unauthorized key access. I'm not making this a Discuss point because it's not exactly my tradeoff to make, but I do want to be sure that this is actually the tradeoff that SIDROPS wants to present to the community. protected channel, e.g., SSH, NetConf (see [RFC6470]), SNMP. This lets the operator escrow the old private key via the mechanism used for operator-generated keys, see Section 5.2, such that it can be re- inserted into a replacement router. The router MAY allow the private key to be to be off-loaded via the protected channel, but this SHOULD be paired with functionality that sets the key into a permanent non- exportable state to ensure that it is not off-loaded at a future time by unauthorized operations. This last sentence is a somewhat different topic and could probably stand alone as its own paragraph. This would also provde the opportunity to clarify that this offload interface is intended for use in conjunction with key generation, and the permanent non-exportable state to be applied thereafter. Appendix A I agree with Mirja about the duplication of content and thus non-need for normative language. |
2019-01-21
|
03 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2019-01-21
|
03 | Mirja Kühlewind | [Ballot comment] I would recommend to remove the normative language from Appendix A ("SHOULD" in the first sentence) as this is, I think, covered in … [Ballot comment] I would recommend to remove the normative language from Appendix A ("SHOULD" in the first sentence) as this is, I think, covered in the security considerations section. If not, it might be worth moving Appendix A to the main body of the document. |
2019-01-21
|
03 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2019-01-18
|
03 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2019-01-17
|
03 | Amy Vezza | Placed on agenda for telechat - 2019-01-24 |
2019-01-17
|
03 | Warren Kumari | Ballot has been issued |
2019-01-17
|
03 | Warren Kumari | [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari |
2019-01-17
|
03 | Warren Kumari | Created "Approve" ballot |
2019-01-17
|
03 | Warren Kumari | Ballot writeup was changed |
2019-01-16
|
03 | Sean Turner | New version available: draft-ietf-sidrops-rtr-keying-03.txt |
2019-01-16
|
03 | (System) | New version approved |
2019-01-16
|
03 | (System) | Request for posting confirmation emailed to previous authors: Keyur Patel , Sean Turner , Randy Bush |
2019-01-16
|
03 | Sean Turner | Uploaded new revision |
2019-01-03
|
02 | Warren Kumari | Ballot writeup was changed |
2018-12-26
|
02 | Scott Bradner | Request for Last Call review by OPSDIR Completed: Serious Issues. Reviewer: Scott Bradner. Sent review to list. |
2018-12-18
|
02 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2018-12-18
|
02 | Sean Turner | New version available: draft-ietf-sidrops-rtr-keying-02.txt |
2018-12-18
|
02 | (System) | New version approved |
2018-12-18
|
02 | (System) | Request for posting confirmation emailed to previous authors: Keyur Patel , Sean Turner , Randy Bush |
2018-12-18
|
02 | Sean Turner | Uploaded new revision |
2018-12-18
|
01 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2018-12-16
|
01 | Dhruv Dhody | Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Dhruv Dhody. |
2018-12-14
|
01 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2018-12-14
|
01 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-sidrops-rtr-keying-01, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-sidrops-rtr-keying-01, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2018-12-11
|
01 | Daniel Franke | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Daniel Franke. Sent review to list. |
2018-12-11
|
01 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Scott Bradner |
2018-12-11
|
01 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Scott Bradner |
2018-12-07
|
01 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Daniel Franke |
2018-12-07
|
01 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Daniel Franke |
2018-12-06
|
01 | Jean Mahoney | Request for Last Call review by GENART is assigned to David Schinazi |
2018-12-06
|
01 | Jean Mahoney | Request for Last Call review by GENART is assigned to David Schinazi |
2018-12-05
|
01 | Min Ye | Request for Last Call review by RTGDIR is assigned to Dhruv Dhody |
2018-12-05
|
01 | Min Ye | Request for Last Call review by RTGDIR is assigned to Dhruv Dhody |
2018-12-05
|
01 | Min Ye | Request for Last Call review by RTGDIR is assigned to Mach Chen |
2018-12-05
|
01 | Min Ye | Request for Last Call review by RTGDIR is assigned to Mach Chen |
2018-12-05
|
01 | Min Ye | Request for Last Call review by RTGDIR is assigned to Daniele Ceccarelli |
2018-12-05
|
01 | Min Ye | Request for Last Call review by RTGDIR is assigned to Daniele Ceccarelli |
2018-12-05
|
01 | Min Ye | Request for Last Call review by RTGDIR is assigned to Stewart Bryant |
2018-12-05
|
01 | Min Ye | Request for Last Call review by RTGDIR is assigned to Stewart Bryant |
2018-12-05
|
01 | Min Ye | Request for Last Call review by RTGDIR is assigned to Patrice Brissette |
2018-12-05
|
01 | Min Ye | Request for Last Call review by RTGDIR is assigned to Patrice Brissette |
2018-12-05
|
01 | Alvaro Retana | Requested Last Call review by RTGDIR |
2018-12-04
|
01 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2018-12-04
|
01 | Cindy Morgan | The following Last Call announcement was sent out (ends 2018-12-18): From: The IESG To: IETF-Announce CC: morrowc@ops-netman.net, sidrops@ietf.org, draft-ietf-sidrops-rtr-keying@ietf.org, sidrops-chairs@ietf.org, Chris … The following Last Call announcement was sent out (ends 2018-12-18): From: The IESG To: IETF-Announce CC: morrowc@ops-netman.net, sidrops@ietf.org, draft-ietf-sidrops-rtr-keying@ietf.org, sidrops-chairs@ietf.org, Chris Morrow , warren@kumari.net Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Router Keying for BGPsec) to Proposed Standard The IESG has received a request from the SIDR Operations WG (sidrops) to consider the following document: - 'Router Keying for BGPsec' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-12-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract BGPsec-speaking routers are provisioned with private keys in order to sign BGPsec announcements. The corresponding public keys are published in the global Resource Public Key Infrastructure, enabling verification of BGPsec messages. This document describes two methods of generating the public-private key-pairs: router-driven and operator-driven. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/ballot/ No IPR declarations have been submitted directly on this I-D. |
2018-12-04
|
01 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2018-12-04
|
01 | Warren Kumari | Last call was requested |
2018-12-04
|
01 | Warren Kumari | Last call announcement was generated |
2018-12-04
|
01 | Warren Kumari | Ballot approval text was generated |
2018-12-04
|
01 | Warren Kumari | Ballot writeup was generated |
2018-12-04
|
01 | Warren Kumari | IESG state changed to Last Call Requested from Publication Requested |
2018-12-04
|
01 | Sean Turner | New version available: draft-ietf-sidrops-rtr-keying-01.txt |
2018-12-04
|
01 | (System) | New version approved |
2018-12-04
|
01 | (System) | Request for posting confirmation emailed to previous authors: Keyur Patel , Sean Turner , Randy Bush |
2018-12-04
|
01 | Sean Turner | Uploaded new revision |
2018-11-05
|
00 | Chris Morrow | Intended Status changed to Proposed Standard from Internet Standard |
2018-11-05
|
00 | Chris Morrow | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary BGPsec-speaking routers are provisioned with private keys in order to sign BGPsec announcements. The corresponding public keys are published in the global Resource Public Key Infrastructure, enabling verification of BGPsec messages. This document describes two methods of generating the public-private key-pairs: router-driven and operator-driven. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? This document started life in SIDR and moved to SIDROPS after the SIDR->SIDROPS move happened. In SIDR this document went through ~16 revision, with comments and discussion along the way. The consensus in SIDR was good, in SIDROPS there've been no objections. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? There are no NITS reported. There are 3 editorial changes inbound at next revision, none alter the intent of the document. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Shepherd: morrowc@ops-netman.net (me) AD: warren@kumari.net - Warren Kumari (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd read several versions to include the final version. it seems sane enough to the shepherd. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? no concerns (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. no required reviews. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. nothing raised. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes, there are no IPR conerns. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. none required. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Good consensus. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) no threats of appeal (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. no nits. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. no formal reviews required (13) Have all references within this document been identified as either normative or informative? yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? no. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. no (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. no (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). no considerations to IANA required. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. no registries required. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. no automated checks/reviews required. |
2018-11-05
|
00 | Chris Morrow | Responsible AD changed to Warren Kumari |
2018-11-05
|
00 | Chris Morrow | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2018-11-05
|
00 | Chris Morrow | IESG state changed to Publication Requested |
2018-11-05
|
00 | Chris Morrow | IESG process started in state Publication Requested |
2018-11-05
|
00 | Chris Morrow | Changed document writeup |
2018-11-05
|
00 | Chris Morrow | Notification list changed to Chris Morrow <morrowc@ops-netman.net> |
2018-11-05
|
00 | Chris Morrow | Document shepherd changed to Chris Morrow |
2018-11-05
|
00 | Chris Morrow | Changed consensus to Yes from Unknown |
2018-11-05
|
00 | Chris Morrow | Intended Status changed to Internet Standard from None |
2018-09-24
|
00 | Chris Morrow | This document now replaces draft-ietf-sidr-rtr-keying instead of None |
2018-09-24
|
00 | Sean Turner | New version available: draft-ietf-sidrops-rtr-keying-00.txt |
2018-09-24
|
00 | (System) | WG -00 approved |
2018-09-21
|
00 | Sean Turner | Set submitter to "Sean Turner ", replaces to draft-ietf-sidr-rtr-keying and sent approval email to group chairs: sidrops-chairs@ietf.org |
2018-09-21
|
00 | Sean Turner | Uploaded new revision |