draft-ietf-sidr-rtr-keying-04.txt   draft-ietf-sidr-rtr-keying-05.txt 
SIDR Working Group S. Turner SIDR Working Group S. Turner
Internet-Draft IECA, Inc. Internet-Draft IECA, Inc.
Intended status: BCP K. Patel Intended status: BCP K. Patel
Expires: June 20, 2014 Cisco Systems Expires: October 31, 2014 Cisco Systems
R. Bush R. Bush
Internet Initiative Japan, Inc. Internet Initiative Japan, Inc.
December 17, 2013 April 29, 2014
Router Keying for BGPsec Router Keying for BGPsec
draft-ietf-sidr-rtr-keying-04 draft-ietf-sidr-rtr-keying-05
Abstract Abstract
BGPsec-speaking routers must be provisioned with private keys and the BGPsec-speaking routers are provisioned with private keys to sign BGP
corresponding public key must be published in the global RPKI messages; the corresponding public keys are published in the global
(Resource Public Key Infrastructure). This document describes two RPKI (Resource Public Key Infrastructure) thereby enabling
ways of provisioning public/private keys, router-driven and operator- verification of BGPsec messages. This document describes two ways of
driven. provisioning the public-private key-pairs: router-driven and
operator-driven.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 August 27, 2013. This Internet-Draft will expire on August 27, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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.
1. Introduction 1. Introduction
BGPsec-speaking routers must be provisioned with private keys and the BGPsec-speaking routers are provisioned with private keys, which
corresponding public key must be published in the global RPKI allow them to digitally sign BGP messages. To verify the signature,
(Resource Public Key Infrastructure). The public key is published in the public key, in the form of a certificate [I-D.ietf-sidr-bgpsec-
the RPKI in the form of a certificate [I-D.ietf-sidr-bgpsec-pki- pki-profiles], is published in the RPKI (Resource Public Key
profiles]. This document describes two methods for generating the Infrastructure). This document describes two methods for
necessary public/private key-pair: router-driven and operator-driven. provisioning the necessary public-private key-pairs: router-driven
and operator-driven.
The difference between the two methods is where the keys are The difference between the two methods is where the keys are
generated: on the router in the router-driven method and elsewhere in generated: on the router in the router-driven method and elsewhere in
the operator-driven model. Different equipment necessitates the two the operator-driven method. Routers are expected to support either
methods. Some equipment doesn't allow the private key to be off- one, the other, or both methods to work in various deployment
loaded while other equipment does. Off-loading private keys supports environments. Some routers may not allow the private key to be off-
hot-swappable routers that need to have the same private key needs loaded while other routers may. Off-loading of private keys would
installed in the soon-to-be online router that was installed in the support swapping of routing engines which could then have the same
soon-to-be offline router. private key installed in the soon-to-be online engine that had
previously been installed in the soon-to-be removed card.
The remainder of this document describes how operators can use the The remainder of this document describes how operators can use the
two methods to provision new and existing routers. two methods to provision new and existing routers.
Note that in both models, the key pair is for algorithms defined in Note: [I-D.ietf-sidr-bgpsec-pki-profiles] specifies the format for
[I-D.ietf-sidr-bgpsec-algs]. The first version specifies ECDSA on the PKCS #10 request and [I-D.ietf-sidr-bgpsec-algs] specifies the
the P-256 curve. algorithms used to generate the signature.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to
"OPTIONAL" in this document are to be interpreted as described in RFC be interpreted as described in RFC 2119 [RFC2119] only when they
2119 [RFC2119]. appear in all upper case. They may also appear in lower or mixed
case as English words, without normative meaning.
It is assumed that the reader understands BGPsec [I-D.ietf-sidr- Readers are assumed to be familiar with the BGPsec protocol [I-
bgpsec-overview] [I-D.ietf-sidr-bgpsec-protocol], the RPKI [RFC6480], D.ietf-sidr-bgpsec-overview][I-D.ietf-sidr-bgpsec-protocol] and the
and [I-D.ietf-sidr-bgpsec-pki-profiles]. RPKI [RFC6480] as well as the BGPsec-specific PKI (Public Key
Infrastructure) specifications [I-D.ietf-sidr-bgpsec-pki-profiles][I-
D.ietf-sidr-bgpsec-algs].
3. Provisioning a New Router 3. Provisioning a New Router
Depending on the options supported by the new router, operators are
free to use either the router-driven or operator-drive methods.
Regardless of the method chosen, operators first establish a secure
communication channel (e.g., via SSH (Secure Shell)) between the
operator's management platform and the router to allow the operator
to securely use the Command Line Interface (CLI). How this channel
is established is router-specific and is not in scope of this
document. Though other configuration mechanisms might be used, e.g.
NetConf (see [RFC6470]), in the remainder of this document, the
secure communication channel between the server and the router is
assumed to be an SSH-protected CLI.
When commissioning a new router, operators may use either the router- Encryption, integrity, authentication, and key exchange algorithms
driven or operator-drive methods. Regardless of the method chosen, used by the secure communication channel SHOULD be of comparable
the operator first needs to establish a secure communication channel strength to BGPsec keys, which currently is 128-bit, or stronger than
with the router. Operators use the router-specific procedures to BGPsec keys. In other words for the encryption algorithm, do not use
enable them to connect to the router via an SSH session. export grade crypto (40-56 bits of security), do not use Triple DES
(112 bits of security), do use something like or better than AES-128:
The SSH encryption, integrity, authentication, and key exchange aes128-cbc [RFC4253] and AEAD_AES_128_GCM [RFC5647]; for integrity
mechanisms used by the router and operator SHOULD be of comparable use something like hmac-sha2-256 [RFC6668] or AESAD_AES_128_GCM
strength to BGPSEC key, which is 128-bit strength, e.g., for [RFC5647]; for authentication use something like ecdsa-sha2-nistp256
encryption: aes128-cbc [RFC4253] and AEAD_AES_128_GCM [RFC5647], for [RFC5656], and; for key exchange use something like ecdh-sha2-
integrity: hmac-sha2-256 [RFC6668] and AESAD_AES_128_GCM [RFC5647], nistp256 [RFC5656].
for authentication: ecdsa-sha2-nistp256 [RFC5656], and for key
exchange: ecdh-sha2-nistp256 [RFC5656].
Note that if the router supports public key certificates at this Note that some routers support the use of public key certificates and
point, which would have had to have been provided by the operator at SSH. The certificates used for the SSH session are different than
this point, x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used for the certificates used for BGPsec. The certificates used with SSH
authentication. The SSH certificate, profiled in [RFC6187], would be should also enable a level of security commensurate with BGPsec keys;
different than the BGPSEC certificate. x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used for
authentication.
3.1. Router-Generated Keys 3.1. Router-Generated Keys
In the router-driven method, once an SSH session is established In the router-driven method, once the SSH-protected CLI session is
between the operator and the router the operator issues a command, or established between the operator and the router, the operator issues
commands, to generate the public/private key pair on the router, to a command, or commands, for the router to generate the public/private
generate the PKCS#10 request that includes the router number and key pair, to generate the PKCS#10 request, and to sign the PKCS#10
public key, and to sign the PKCS#10 with the private key. [I-D.ietf- with the private key. Once generated, the PKCS#10, which includes
sidr-bgpsec-pki-profiles] specifies the format for the PKCS #10 the public key the router wants certified, is transmitted to the RPKI
request and the algorithm used to generate the signature is specified CA for the CA to certify. This can be via a number of means, two of
in [I-D.ietf-sidr-bgpsec-algs]. which might be as follows:
The PKCS#10 request, which includes the public key the router wants o Through the SSH-protected CLI session with the operator's RPKI
certified, can be transferred to the RPKI CA over the network if the management platform: The operator off-loads the PKCS#10 and
router supports protocols such as FTP and HTTP [RFC2585] using the uploads the request to the CA. If the CA is operated by an
application/pkcs10 media type [RFC5967] or EST (Enrollment over external entity, external network connectivity likely is
Secure Transport) [I-D.ietf-pkix-est]; direct transfer assumes that required.
the router has direct connectivity to the CA. The CA returns a
successful request as a PKCS#7 [I-D.ietf-sidr-bgpsec-pki-profiles],
which includes the certificate, and uploads the certificate to the
global RPKI. The response can be returned using the
application/pkcs7-mime media type [RFC5751] if the router supports
protocols such as FTP and HTTP.
The PKCS#10 request can also be indirectly transferred to the RPKI CA o Between the router and the CA: The operator, through a command or
through the operator. The operator off-loads the PKCS#10 and uploads commands, prompts the router to send/transfer the PKCS#10 request
the request to its RPKI software management tools; external network to the CA over the network. Obviously for this to work, the
connectivity is not required when the operator acts as the CA. The router requires network connectivity with the CA and if the CA is
tools create the certificate and publish the certificate in the operated by an external entity external network connectivity may
global RPKI, and return the PKCS#7 to the router; publication of the be required.
certificate in the global RPKI requires external network
connectivity. After the CA certifies the key, it does two things:
o Publishes the certificate in the Global RPKI. The CA must have
connectivity to the relevant publication point, which in turn
must have external network connectivity as it is part of the
Global RPKI.
o Returns the certificate to the operator's management station or
to the router, normally packaged in a PKCS#7, using the
corresponding method by which it received the certificate
request.
With network connectivity, the router and CA can exchange the
certificate request and the certificate using the application/pkcs10
media type [RFC5967] and application/pkcs7-mime [RFC5751],
respectively, with the FTP [RFC2585], the HTTP [RFC2585], or the EST
(Enrollment over Secure Transport) [I-D.ietf-pkix-est].
The router SHOULD extract the certificate from the PCKCS#7 and verify The router SHOULD extract the certificate from the PCKCS#7 and verify
that the private key corresponds to the returned public key. The that the private key it holds corresponds to the returned public key.
router SHOULD inform the operator that it has successfully received The router SHOULD inform the operator that the certificate was
its certificate; this mechanism is out of scope. When the keys do received; by some mechanism which is out of scope of this document.
not correspond, the router SHOULD inform the operator; this mechanism The router SHOULD inform the operator whether or not the keys
is out of scope. The router SHOULD also verify the returned correspond, again by a mechanism which is out of scope for this
certificate back to a trust anchor, but to perform this verification document.
either the CA's certificate needs to be installed on the router via
the CLI or the CA's certificate needs to be returned along with the The router SHOULD also verify that the returned certificate validates
router's certificate in the PKCS#7. The router SHOULD inform the back to a trust anchor. To perform this verification either the CA's
operator if the signature does not validate to a trust anchor; this certificate needs to be installed on the router via the CLI or the
CA's certificate needs to be returned along with the router's
certificate in the PKCS#7. The router SHOULD inform the operator
whether or not the signature validates to a trust anchor; this
notification mechanism is out of scope. After performing these notification mechanism is out of scope. After performing these
checks, the router need not retain the certificate. checks, the router need not retain the CA's certificate because the
certificate is not transmitted as part of BGPsec messages.
Note that even if the operator can not get the private key off the Note that even if the operator cannot extract the private key from
router this signature still provides a linkage between a private key the router, this signature still provides a linkage between a private
and a router. That is the server can verify the proof of possession key and a router. That is the server can verify the proof of
(POP), as required by [RFC6484]. possession (POP), as required by [RFC6484].
3.2. Operator-Generated Keys 3.2. Operator-Generated Keys
In the operator-driven method, the operator generates the private key In the operator-driven method, the operator generates the
and it is installed over the SSH connection established between the public/private key pair and installs the private key into the router
operator and the router. Note that cut/copy and paste operations for over the SSH-protected CLI session. Note that cut/copy and paste
keys over a certain sizes is error-prone. operations for keys over a certain sizes is error-prone.
The operator uses their RPKI management tools to generate the keys, The operator uses RPKI management tools to generate the keys, the
the PKCS#10 certification request, the certificate, and the PKCS#7 PKCS#10 certification request, the certificate, and the PKCS#7
certification response as well as publish the certificate for the certification response, as well as publishing the certificate in the
public key in the global RPKI. The only reason global network Global RPKI. External network connectivity may needed if the
connectivity might be needed would be to publish the certificate in certificate is to be published in the Global RPKI.
the global RPKI. The private key MUST support the algorithm
specified in [I-D.ietf-sidr-bgpsec-algs], which for ECDSA is
specified in [RFC5915]. The PKCS#10 and PKCS#7 are as specified in
[I-D.ietf-sidr-bgpsec-pki-profiles].
Along with the PKCS#7, the operator returns the private key. The Along with the PKCS#7, the operator returns the private key. The
private key is encapsulated in a PKCS #8 [RFC5958], the PKCS#8 is private key is encapsulated in a PKCS #8 [RFC5958], the PKCS#8 is
further encapsulated in a CMS (Cryptographic Message Syntax) further encapsulated in CMS (Cryptographic Message Syntax) SignedData
SignedData [RFC5652], and signed by the operator's EE certificate. [RFC5652], and signed by the AS's EE (End Entity) certificate.
The router SHOULD verify the signature on the encapsulated PKCS#8 to The router SHOULD verify the signature of the encapsulated PKCS#8 to
ensure the returned private key in fact came from the operator, but ensure the returned private key did in fact come from the operator,
this requires that the operator also provision via the CLI or include but this requires that the operator also provision via the CLI or
in the SignedData the RPKI CA certificates and operator's EE include in the SignedData the RPKI CA certificate and relevant AS's
certificates. The router SHOULD inform the operator if the signature EE certificate(s). The router SHOULD inform the operator whether or
does not validate to a trust anchor; this notification mechanism is not the signature validates to a trust anchor; this notification
out of scope. mechanism is out of scope.
The router SHOULD extract the certificate for the PKCS#7 and verify The router SHOULD extract the certificate from the PKCS#7 and verify
that the private key corresponds to the returned public key. The that the private key corresponds to the returned public key. The
router SHOULD inform the operator that it has successfully received router SHOULD inform the operator whether it successfully received
its certificate; this mechanism is out of scope. When the keys do the certificate; this mechanism is out of scope. The router should
not correspond, the router SHOULD inform the operator; this mechanism inform the operator whether or not the keys correspond; this
is out of scope. The router SHOULD also verify the returned mechanism is out of scope. The router SHOULD also verify the
certificate back to a trust anchor, but to perform this verification returned certificate back to a trust anchor, but to perform this
either the CA's certificate needs to be installed on the router via verification either the CA's certificate needs to be installed on the
the CLI or the CA's certificate needs to be returned along with the router via the CLI or the CA's certificate needs to be returned along
router's certificate in the PKCS#7. The router SHOULD inform the with the router's certificate in the PKCS#7. The router SHOULD
operator if the signature does not validate to a trust anchor; this inform the operator whether or not the signature validates to a trust
notification mechanism is out of scope. After performing these anchor; this notification mechanism is out of scope. After
checks, the router need not retain the certificate. performing these checks, the router need not retain the CA
certificate.
4. Key rollover 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 CA.
TBD 4. Key Management
An operator's responsibilities do not end after key generation, key
provisioning, certificate issuance, and certificate distribution.
They persist for as long as the operator wishes to operate the
BGPsec-speaking router.
Paramount to maintaining a router that can be a continuous BPGsec
speaker is ensuring that the router has a valid certificate at all
times. To ensure this, the operator needs to ensure the router
always has a non-expired certificate. That is the key used when BGP-
speaking always has an associated certificate whose expiry time is
after the current time.
Ensuring this is not terribly difficult but requires that either:
o The router has a mechanism to notify the operator that the
certificate has an impending expiration, and/or
o The operator notes the expiry time of the certificate and uses a
calendaring program to remind them of the expiry time. It is
advisable that the expiration warning happen well in advance of
the actual expiry time, and/or
o The RPKI CA warns the operaor of pending expiration, and/or
o Use some other kind of automated process to search for and track
the expiry times of router certificates.
Regardless of the technique used to track router certificate expiry
times, it is advisable to notify additional operators in the same
organization as the expiry time approaches thereby ensuring that the
forgetfulness of one operator does not affect the entire
organization.
Depending on inter-operator relationship, it may be appropriate to
notify a peer operator that one or more of their certificates are
about to expire.
Routers that support multiple private keys also greatly increase the
chance that routers can continuously speak BGPsec because the new
private key and certificate can be obtained prior to expiration of
the operational key. Obviously, the router needs to know when to
start using the new key. Once the new key is being used, having the
already distributed certificate ensures continuous operation.
Whether the certificate is rekeyed (i.e., different key in the
certificate with a new expiry time) or renewed (i.e., the same key in
the certificate with a new expiry time) depends on the key's lifetime
and operational use. Arguably, rekeying the router's BGPsec
certificate every time the certificate expires is more secure than
renewal because it limits the private key's exposure. However, if
the key is not compromised the certificate could be renewed as many
times as allowed by the operator's security policy. Routers that
support only one key can use renewal to ensure continuous operation,
assuming the certificate is renewed and distributed prior to the
operational's certificate expiry time.
Certain unfortunate circumstances exist when the operator will need
to revoke the router's BGPsec certificate. When this occurs, the
operator needs to use the RPKI CA system to revoke the certificate by
placing the router's BGPsec certificate on the CRL (Certificate
Revocation List) as well as rekeying the router's certificate.
5. Other Use Cases 5. Other Use Cases
Current router code generates private keys for uses such as SSH, but Current router code generates private keys for uses such as SSH, but
the private keys may not be seen or off-loaded via CLI or any other the private keys may not be seen or off-loaded via the SSH-protected
means. While this is good security, it creates difficulties when a CLI session or any other means. While this is good security, it
routing engine or whole router must be replaced in the field and all creates difficulties when a routing engine or whole router must be
software which accesses the router must be updated with the new keys. replaced in the field and all software which accesses the router must
Also, the initial contact with a new routing engine requires trust in be updated with the new keys. Also, any network based initial contact
the public key presented on first 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 To allow operators to quickly replace routers without requiring
update and distribution of the corresponding public keys in the RPKI, update and distribution of the corresponding public keys in the RPKI,
routers SHOULD allow the private BGPsec key to be off-loaded via the routers SHOULD allow the private BGPsec key to be off-loaded via the
CLI, NetConf (see [RFC6470]), SNMP, etc. This lets the operator SSH-protected CLI, NetConf (see [RFC6470]), SNMP, etc. This lets the
upload the old private key via the mechanism used for operator- operator upload the old private key via the mechanism used for
generated keys, see Section 3.2. operator-generated keys, see Section 3.2.
6. Security Considerations 6. Security Considerations
Operator-generated keys could be intercepted in transport and the Operator-generated keys could be intercepted in transport and the
recipient router would have no way of knowing a substitution had been recipient router would have no way of knowing a substitution had been
made or that the key had been disclosed by a monkey in the middle. made or that the key had been disclosed by a monkey in the middle.
Hence transport security is strongly RECOMMENDED. As noted in Hence transport security is strongly RECOMMENDED. As noted in
Section 3, the level of security provided by the transport security Section 3, the level of security provided by the transport security
SHOULD be commensurate with the BGPsec key. Additionally, operators SHOULD be commensurate with the BGPsec key. Additionally, operators
SHOULD ensure the transport security implementation is up to date and SHOULD ensure the transport security implementation is up to date and
skipping to change at page 6, line 13 skipping to change at page 8, line 11
protected in a secure fashion. Disclosure of the private key leads protected in a secure fashion. Disclosure of the private key leads
to masquerade [RFC4949]. The local storage format for the private to masquerade [RFC4949]. The local storage format for the private
key is a local matter. key is a local matter.
Though the CA's certificate is installed on the router and used to Though the CA's certificate is installed on the router and used to
verify the returned certificate is in fact signed by the CA, the verify the returned certificate is in fact signed by the CA, the
revocation status of the CA's certificate is not checked. The revocation status of the CA's certificate is not checked. The
operator MUST ensure that installed CA certificate is valid. operator MUST ensure that installed CA certificate is valid.
Operators need to manage their SSH keys to ensure only those Operators need to manage their SSH keys to ensure only those
authorized to access the router can. As employees no longer need authorized to access the router may do so. As employees no longer
access to the router, their keys SHOULD be removed from the router. need access to the router, their keys SHOULD be removed from the
router.
7. IANA Considerations 7. IANA Considerations
This document has no IANA Considerations. This document has no IANA Considerations.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 6, line 45 skipping to change at page 8, line 44
RFC 5652, September 2009. RFC 5652, September 2009.
[RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key [RFC5915] Turner, S. and D. Brown, "Elliptic Curve Private Key
Structure", RFC 5915, June 2010. Structure", RFC 5915, June 2010.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August
2010. 2010.
[I-D.ietf-sidr-bgpsec-algs] [I-D.ietf-sidr-bgpsec-algs]
Turner, S., "BGP Algorithms, Key Formats, & Signature Turner, S., "BGP Algorithms, Key Formats, & Signature
Formats", draft-ietf-sidr-bgpsec-algs (work in progress), Formats", draft-ietf-sidr-bgpsec-algs (work in progress).
September 2013.
[I-D.ietf-sidr-bgpsec-pki-profiles] [I-D.ietf-sidr-bgpsec-pki-profiles]
Reynolds, M., Turner, S., and S. Kent, "A Profile for Reynolds, M., Turner, S., and S. Kent, "A Profile for
BGPSEC Router Certificates, Certificate Revocation Lists, BGPSEC Router Certificates, Certificate Revocation Lists,
and Certification Requests", and Certification Requests",
draft-ietf-sidr-bgpsec-pki-profiles (work in progress), draft-ietf-sidr-bgpsec-pki-profiles (work in progress).
September 2013.
8.2. Informative References 8.2. Informative References
[I-D.ietf-sidr-bgpsec-overview] [I-D.ietf-sidr-bgpsec-overview]
Lepinski, M. and S. Turner, "An Overview of BGPSEC", Lepinski, M. and S. Turner, "An Overview of BGPSEC",
draft-ietf-sidr-bgpsec-overview (work in progress), draft-ietf-sidr-bgpsec-overview (work in progress).
December 2013.
[I-D.ietf-sidr-bgpsec-protocol] [I-D.ietf-sidr-bgpsec-protocol]
Lepinski, M., "BGPSEC Protocol Specification", Lepinski, M., "BGPSEC Protocol Specification",
draft-ietf-sidr-bgpsec-protocol (work in progress), draft-ietf-sidr-bgpsec-protocol (work in progress).
November 2013.
[I-D.ietf-pkix-est]
Pritikin, M, Yee, P., and D. Harkins "Enrollment over
Secure Transport", RFC 7030, October 2013.
[IEEE-802.3] [IEEE-802.3]
ISO/IEC 8802-3 Information technology - ISO/IEC 8802-3 Information technology -
Telecommunications and information exchange between Telecommunications and information exchange between
systems - Local and metropolitan area networks - systems - Local and metropolitan area networks -
Common specifications - Part 3: Carrier Sense Common specifications - Part 3: Carrier Sense
Multiple Access with Collision Detection (CSMA/CD) Multiple Access with Collision Detection (CSMA/CD)
Access Method and Physical Layer Specifications, 2008. Access Method and Physical Layer Specifications, 2008.
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
skipping to change at page 8, line 12 skipping to change at page 9, line 49
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010. Specification", RFC 5751, January 2010.
[RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, [RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967,
August 2010. August 2010.
[RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure
Shell Authentication", RFC 6187, March 2011. Shell Authentication", RFC 6187, March 2011.
[RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF)
Base Notifications", RFC 6470, February 2012.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, February 2012.
[RFC6668] Bider, D. and M. Baushke, "SHA-2 Data Integrity
Verification for the Secure Shell (SSH) Transport Layer
Protocol", RFC 6668, July 2012.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030, October
2013.
Authors' Addresses Authors' Addresses
Sean Turner Sean Turner
IECA, Inc. IECA, Inc.
3057 Nutley Street, Suite 106 3057 Nutley Street, Suite 106
Fairfax, Virginia 22031 Fairfax, Virginia 22031
US US
Email: turners@ieca.com Email: turners@ieca.com
 End of changes. 35 change blocks. 
149 lines changed or deleted 248 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/