diff options
Diffstat (limited to 'doc/protocol/draft-ietf-netconf-tls-01.txt')
| -rw-r--r-- | doc/protocol/draft-ietf-netconf-tls-01.txt | 485 |
1 files changed, 0 insertions, 485 deletions
diff --git a/doc/protocol/draft-ietf-netconf-tls-01.txt b/doc/protocol/draft-ietf-netconf-tls-01.txt deleted file mode 100644 index 70efb526ba..0000000000 --- a/doc/protocol/draft-ietf-netconf-tls-01.txt +++ /dev/null @@ -1,485 +0,0 @@ -NETCONF Working Group Mohamad Badra -Internet Draft LIMOS Laboratory -Intended status: Standards Track February 15, 2008 -Expires: August 2008 - - - - NETCONF over Transport Layer Security (TLS) - draft-ietf-netconf-tls-01.txt - - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - 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." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - This Internet-Draft will expire on August 15, 2008. - -Copyright Notice - - Copyright (C) The IETF Trust (2008). - -Abstract - - The Network Configuration Protocol (NETCONF) provides mechanisms to - install, manipulate, and delete the configuration of network devices. - This document describes how to use the Transport Layer Protocol (TLS) - to secure NETCONF exchanges. - - - - - -Badra Expires August 15, 2008 [Page 1] - -Internet-Draft NETCONF over TLS February 2008 - - -Table of Contents - - - 1. Introduction...................................................2 - 1.1. Conventions used in this document.........................2 - 2. NETCONF over TLS...............................................3 - 2.1. Connection Initiation.....................................3 - 2.2. Connection Closure........................................3 - 3. Endpoint Authentication and Identification.....................4 - 3.1. Server Identity...........................................4 - 3.2. Client Identity...........................................5 - 3.3. Password-Based Authentication.............................5 - 4. Cipher Suite Requirements......................................7 - 5. Security Considerations........................................7 - 6. IANA Considerations............................................7 - 7. Acknowledgments................................................7 - 8. References.....................................................7 - 8.1. Normative References......................................7 - Author's Addresses................................................8 - Intellectual Property Statement...................................8 - Disclaimer of Validity............................................9 - -1. Introduction - - The NETCONF protocol [RFC4741] defines a simple mechanism through - which a network device can be managed. NETCONF is connection- - oriented, requiring a persistent connection between peers. This - connection must provide reliable, sequenced data delivery, integrity - and confidentiality and peers authentication. This document - describes how to use TLS [RFC4346] to secure NETCONF connections. - - Throughout this document, the terms "client" and "server" are used to - refer to the two ends of the TLS connection. The client actively - opens the TLS connection, and the server passively listens for the - incoming TLS connection. The terms "manager" and "agent" are used to - refer to the two ends of the NETCONF protocol session. The manager - issues NETCONF remote procedure call (RPC) commands, and the agent - replies to those commands. When NETCONF is run over TLS using the - mapping defined in this document, the client is always the manager, - and the server is always the agent. - -1.1. Conventions used in this document - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC-2119 [RFC2119]. - - - -Badra Expires August 15, 2008 [Page 2] - -Internet-Draft NETCONF over TLS February 2008 - - -2. NETCONF over TLS - - Since TLS is application protocol-independent, NETCONF can operate on - top of the TLS protocol transparently. This document defines how - NETCONF can be used within a Transport Layer Security (TLS) session. - -2.1. Connection Initiation - - The peer acting as the NETCONF manager MUST also act as the TLS - client. It MUST connect to the server that passively listens for the - incoming TLS connection on the IANA-to-be-assigned TCP port <TBA>. - It MUST therefore send the TLS ClientHello to begin the TLS - handshake. Once the TLS handshake has been finished, the client and - the server MAY then send their NETCONF exchanges. In particular, the - client will send complete XML documents to the server containing - <rpc> elements, and the server will respond with complete XML - documents containing <rpc-reply> elements. The client MAY indicate - interest in receiving event notifications from a NETCONF server by - creating a subscription to receive event notifications [NETNOT], in - which the NETCONF server replies to indicate whether the subscription - request was successful and, if it was successful, begins sending the - event notifications to the NETCONF client as the events occur within - the system. All these elements are encapsulated into TLS records of - type "application data". These records are protected using the TLS - material keys. - - Current NETCONF messages don't include a message's length. This - document uses consequently the same delimiter sequence defined in - [RFC4742] and therefore the special character sequence, ]]>]]>, to - delimit XML documents. - -2.2. Connection Closure - - Either NETCONF peer MAY stop the NETCONF connection at any time and - therefore notify the other NETCONF peer that no more data on this - channel will be sent and that any data received after a closure - request will be ignored. This MAY happen when no data is received - from a connection for a long time, where the application decides what - "long" means. - - TLS has the ability for secure connection closure using the Alert - protocol. When the NETCONF peer processes a closure request of the - NETCONF connection, it MUST send a TLS close_notify alert before - closing the connection. Any data received after a closure alert is - ignored. - - - - -Badra Expires August 15, 2008 [Page 3] - -Internet-Draft NETCONF over TLS February 2008 - - - Unless some other fatal alert has been transmitted, each party is - required to send a close_notify alert before closing the write side - of the connection. The other party MUST respond with a close_notify - alert of its own and close down the connection immediately, - discarding any pending writes. It is not required for the initiator - of the close to wait for the responding close_notify alert before - closing the read side of the connection. - -3. Endpoint Authentication and Identification - - NETCONF requires that its transport provide mutual authentication of - client and server, so cipher suites that are anonymous or which only - authenticate the server to the client MUST NOT be used with NETCONF. - This document specifies how to use TLS with endpoint authentication - in TLS can be based on either preshared keys [RFC4279] or public key - certificates [RFC4346]. Some cipher suites (e.g. - TLS_RSA_PSK_WITH_AES_128_CBC_SHA) use both. Section 3.1 describes - how the client authenticates the server if public key certificates - are provided by the server, section 3.2 describes how the server - authenticates the client if public key certificates are provided by - the client, and section 3.3 describes how the client and server - mutually authenticate one another using a password. - -3.1. Server Identity - - During the TLS negotiation, the client MUST carefully examine the - certificate presented by the server to determine if it meets their - expectations. Particularly, the client MUST check its understanding - of the server hostname against the server's identity as presented in - the server Certificate message, in order to prevent man-in-the-middle - attacks. - - Matching is performed according to these rules [RFC4642]: - - - The client MUST use the server hostname it used to open the - connection (or the hostname specified in TLS "server_name" - extension [RFC4366]) as the value to compare against the server - name as expressed in the server certificate. The client MUST - NOT use any form of the server hostname derived from an - insecure remote source (e.g., insecure DNS lookup). CNAME - canonicalization is not done. - - - If a subjectAltName extension of type dNSName is present in the - certificate, it MUST be used as the source of the server's - identity. - - - Matching is case-insensitive. - - -Badra Expires August 15, 2008 [Page 4] - -Internet-Draft NETCONF over TLS February 2008 - - - - A "*" wildcard character MAY be used as the left-most name - component in the certificate. For example, *.example.com would - match a.example.com, foo.example.com, etc., but would not match - example.com. - - - If the certificate contains multiple names (e.g., more than one - dNSName field), then a match with any one of the fields is - considered acceptable. - - If the match fails, the client MUST either ask for explicit user - confirmation or terminate the connection and indicate the server's - identity is suspect. - - Additionally, clients MUST verify the binding between the identity of - the servers to which they connect and the public keys presented by - those servers. Clients SHOULD implement the algorithm in Section 6 - of [RFC3280] for general certificate validation, but MAY supplement - that algorithm with other validation methods that achieve equivalent - levels of verification (such as comparing the server certificate - against a local store of already-verified certificates and identity - bindings). - - If the client has external information as to the expected identity of - the server, the hostname check MAY be omitted. - -3.2. Client Identity - - Typically, the server has no external knowledge of what the client's - identity ought to be and so checks (other than that the client has a - certificate chain rooted in an appropriate CA) are not possible. If - a server has such knowledge (typically from some source external to - NETCONF or TLS) it MUST check the identity as described above. - -3.3. Password-Based Authentication - - [RFC4279] supports authentication based on pre-shared keys (PSKs). - These pre-shared keys are symmetric keys, shared in advance among the - communicating parties. - - The PSK can be generated in many ways and its length is variable. - Implementation of this document MAY rely on [RFC4279] to enable - password based user authentication. In this case, the password is - used to generate the PSK. It is RECOMMENDED that implementations - that allow the administrator to manually configure the password also - provide functionality for generating a new random password, taking - [RFC4086] into account. - - - -Badra Expires August 15, 2008 [Page 5] - -Internet-Draft NETCONF over TLS February 2008 - - - This document generates the PSK from the password as follow: - - PSK = SHA-1(SHA-1(password + psk_identity + "Key Pad for Netconf") + - psk_identity_hint) - - Where + means concatenation. - - The label "Key Pad for Netconf" is an ASCII string. - - The psk_identity_hint is initially defined in section 5.1 of - [RFC4279]. The psk_identity_hint can do double duty and also provide - a form of server authentication in the case where the user has the - same password on a number of NETCONF servers. If a hint is provided, - the psk_identity_hint is encoded in the same way as in [RFC4279] and - should be a string representation of the name of the server - recognizable to the administrator or his software. In the case where - the user types a server name to connect to, it should be that string. - If the string the user enters differs from the one returned as - psk_identity_hint, the software could display the server's name and - ask the user to confirm. For automated scripts, the names could be - expected to match. It is highly recommended that implementations set - the psk_identity_hint to the DNS name of the NETCONF server (i.e., - the TLS server). - - It is RECOMMENDED that users choose different passwords for the - different servers they manage. - - Note 1: The NETCONF over TLS implementation need not store the - password in clear text, but rather can store the value of SHA- - 1(SHA-1(password + psk_identity + "Key Pad for Netconf") + - psk_identity_hint), which could not be used as a password - equivalent for applications other than NETCONF. Deriving the PSK - from a password is not secure. This construction is used because - it is anticipated that people will do it anyway. - - Note 2: [RFC4279] defines some conformance requirements for the - PSK, for the PSK identity encoding and for the identity hint. The - same requirements apply here as well; in particular on the - password. Moreover, the management interface by which the - password is provided MUST accept ASCII strings of at least 64 - octets and MUST NOT add a null terminator before using them as - shared secrets. It MUST also accept a HEX encoding of the - password. The management interface MAY accept other encodings if - the algorithm for translating the encoding to a binary string is - specified. - - - - -Badra Expires August 15, 2008 [Page 6] - -Internet-Draft NETCONF over TLS February 2008 - - -4. Cipher Suite Requirements - - A compliant implementation of the protocol specified in this document - MUST implement the cipher suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA and - MAY implement any TLS cipher suite that provides mutual - authentication. - -5. Security Considerations - - The security considerations described throughout [RFC4346] and - [RFC4279] apply here as well. - - As with all schemes involving shared keys and passwords, special care - should be taken to protect the shared values and passwords as well as - to limit their exposure over time. Alternatively, using certificates - would provide better protection. - -6. IANA Considerations - - IANA is requested to assign a TCP port number that will be the - default port for NETCONF over TLS sessions as defined in this - document. - - IANA has assigned port <TBA> for this purpose. - -7. Acknowledgments - - A significant amount of the text in this document was lifted from - [RFC4642]. - - The author would like to acknowledge David Harrington, Miao Fuyou, - Eric Rescorla, Juergen Schoenwaelder and the NETCONF mailing list - members for their comments on the document. The author appreciates - also Bert Wijnen and Dan Romascanu for their efforts on issues - resolving discussion, and Charlie Kaufman for the thorough review of - this document and for the helpful comments on the password-based - authentication. - -8. References - -8.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - - - - -Badra Expires August 15, 2008 [Page 7] - -Internet-Draft NETCONF over TLS February 2008 - - - [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet - X.509 Public Key Infrastructure Certificate and Certificate - Revocation List (CRL) Profile", RFC 3280, April 2002. - - [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, - "Randomness Requirements for Security", BCP 106, RFC 4086, - June 2005. - - [RFC4279] Eronen, P. and H. Tschofenig., "Pre-Shared Key Ciphersuites - for Transport Layer Security (TLS)", RFC 4279, December - 2005. - - [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security - (TLS) Protocol 1.1", RFC 4346, April 2006. - - [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., - and T. Wright, "Transport Layer Security (TLS) Extensions", - RFC 4366, April 2006. - - [RFC4642] Murchison, K., Vinocur, J., Newman, C., "Using Transport - Layer Security (TLS) with Network News Transfer Protocol - (NNTP)", RFC 4642, October 2006 - - [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, - December 2006. - - [RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF - Configuration Protocol over Secure Shell (SSH)", RFC 4742, - December 2006. - - [NETNOT] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", - draft-ietf-netconf-notification-11.txt, (work in progress), - November 2007. - -Author's Addresses - - Mohamad Badra - LIMOS Laboratory - UMR6158, CNRS - France - - Email: badra@isima.fr - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - - -Badra Expires August 15, 2008 [Page 8] - -Internet-Draft NETCONF over TLS February 2008 - - - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Copyright Statement - - Copyright (C) The IETF Trust (2008). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - -Badra Expires August 15, 2008 [Page 9] - |