From edcb6ed3578b922ba0690cb89f5cb48d51946300 Mon Sep 17 00:00:00 2001 From: Simon Josefsson Date: Wed, 4 Jun 2008 10:58:33 +0200 Subject: Add. --- doc/protocol/draft-ietf-netconf-tls-02.txt | 809 +++++++++++++++++++++++++++++ 1 file changed, 809 insertions(+) create mode 100644 doc/protocol/draft-ietf-netconf-tls-02.txt (limited to 'doc') diff --git a/doc/protocol/draft-ietf-netconf-tls-02.txt b/doc/protocol/draft-ietf-netconf-tls-02.txt new file mode 100644 index 0000000000..2c37fa6a81 --- /dev/null +++ b/doc/protocol/draft-ietf-netconf-tls-02.txt @@ -0,0 +1,809 @@ +NETCONF Working Group Mohamad Badra +Internet Draft LIMOS Laboratory +Intended status: Standards Track May 27, 2008 +Expires: November 2008 + + + + NETCONF over Transport Layer Security (TLS) + draft-ietf-netconf-tls-02.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 November 27, 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 November 27, 2008 [Page 1] + +Internet-Draft NETCONF over TLS May 2008 + + +Table of Contents + + + 1. Introduction...................................................3 + 1.1. Conventions used in this document.........................3 + 2. NETCONF over TLS...............................................3 + 2.1. Connection Initiation.....................................3 + 2.2. Connection Closure........................................4 + 3. Endpoint Authentication and Identification.....................4 + 3.1. Server Identity...........................................5 + 3.2. Client Identity...........................................6 + 3.3. Password-Based Authentication.............................6 + 4. Cipher Suite Requirements......................................7 + 5. Security Considerations........................................7 + 6. IANA Considerations............................................7 + 7. Acknowledgments................................................8 + A. Appendix - Test Vectors for the PSK Derivation Function........9 + B. Appendix - Enabling Third Party Authentication using Passwords10 + B.1. Working Group discussion at the 71st IETF meeting........12 + Normative References.............................................13 + Authors' Addresses...............................................14 + Intellectual Property and Copyright Statements...................14 + + + + + + + + + + + + + + + + + + + + + + + + + + + +Badra Expires November 27, 2008 [Page 2] + +Internet-Draft NETCONF over TLS May 2008 + + +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]. + +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 . + 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 + elements, and the server will respond with complete XML + documents containing elements. The client MAY indicate + interest in receiving event notifications from a NETCONF server by + creating a subscription to receive event notifications [I-D.ietf-- + netconf-notification], 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 + + +Badra Expires November 27, 2008 [Page 3] + +Internet-Draft NETCONF over TLS May 2008 + + + 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 closes the NETCONF connection, it + MUST send a TLS close_notify alert before closing the TCP connection. + Any data received after a closure alert is ignored. + + Unless a fatal error has occurred, each party is required to send a + close_notify alert before closing the write side of the connection + [RFC4346]. 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, + which 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. + + + + + +Badra Expires November 27, 2008 [Page 4] + +Internet-Draft NETCONF over TLS May 2008 + + +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. + + - 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 [RFC5280] 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). + + + +Badra Expires November 27, 2008 [Page 5] + +Internet-Draft NETCONF over TLS May 2008 + + + 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. + + This document generates the PSK from the password as follow: + + PSK = SHA-1(SHA-1(psk_identity + "Key Pad for Netconf" + password) + + 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 + + + +Badra Expires November 27, 2008 [Page 6] + +Internet-Draft NETCONF over TLS May 2008 + + + 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 the + inner SHA-1 (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. + +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. + + +Badra Expires November 27, 2008 [Page 7] + +Internet-Draft NETCONF over TLS May 2008 + + + IANA has assigned port for this purpose. + +7. Acknowledgments + + A significant amount of the text in Section 3.1 was lifted from + [RFC4642]. + + The author would like to acknowledge David Harrington, Miao Fuyou, + Eric Rescorla, Juergen Schoenwaelder, Simon Josefsson, Olivier + Coupelon and the NETCONF mailing list members for their comments on + the document. The author appreciates also Bert Wijnen, Mehmet Ersue + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Badra Expires November 27, 2008 [Page 8] + +Internet-Draft NETCONF over TLS May 2008 + + +A. Appendix - Test Vectors for the PSK Derivation Function + + The test vectors for the PSK derivation function in this document + have been cross-verified by two independent implementations. An + implementation that concurs with the results provided in this + document should be interoperable with other similar implementations. + + password = password + psk_identity = psk_identity + psk_identity_hint = psk_identity_hint + + The inner SHA-1 value (in hex): + + inner := SHA-1(password + psk_identity + "Key Pad for Netconf") + == SHA-1("psk_identityKey Pad for Netconfpassword") + => 6d6eeb6a b8d0466b 45245d07 47d86726 b41b868c + + The outer SHA-1 value (in hex): + + outer := SHA-1(inner + psk_identity_hint) + => 88f3824b 3e5659f5 2d00e959 bacab954 b6540344 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Badra Expires November 27, 2008 [Page 9] + +Internet-Draft NETCONF over TLS May 2008 + + +B. Appendix - Enabling Third Party Authentication using Passwords + + During the 71st IETF meeting, several proposals have been proposed to + enable third party authentication that could be used in combination + with existing user authentication databases such as RADIUS. They are + listed below. More details on those proposals may be found at + https://www3.ietf.org/proceedings/08mar/slides/netconf-1/netconf- + 1.htm and + http://www.psg.com/lists/netconf/netconf.2008/msg00125.html. + + We summarize them as following: + + 1. Defining RPC: + -------------------------- + + This option relies on JUNOS mechanism to enable an authentication + function via third parties. It consists of establishing a TLS with + no manager authentication, leaving the RPC as the + only valid RPC. Anything else is an error. + + Once the TLS session is established, the agent MUST authenticate + the manager by emitting the following tag element: + + + Password: + + + In which the manager MUST reply with the following: + + + + password + + + + The rules to handle this were pretty simple: + + - The RPC could only be performed if the session + wasn't authenticated. + + - No other RPCs could be performed if the session wasn't + authenticated. + + - The transport protocol can authenticate the session + (internally). + + + +Badra Expires November 27, 2008 [Page 10] + +Internet-Draft NETCONF over TLS May 2008 + + + + + Pros and cons: + + o is simple to do. But + + o might raise questions from the security ADs; NETCONF assumes + the authentication is part of the transport not NETCONF. + + o only works for plaintext passwords (SASL PLAIN). + + 2. Enhancing TLS: + -------------- + + The second option consists of extending TLS so the manager + authentication becomes part of TLS. This extension, detailed in + http://tools.ietf.org/id/draft-badra-tls-password-ext-01.txt, + defines a new extension and a new TLS message to the TLS protocol + to enable TLS client authentication using passwords. The extension + is used to convey the manager login, whereas the new message is + defined and sent by the manager to prove its knowledge of the + password. + + Steps during the TLS negotiation: + + - The manager adds such an extension to its TLS ClientHello. + + - If the agent agrees on using this extension, it will notify + the manager and replies with its certificate and/or its + authenticated public key. + + - The manager generates a premaster secret and encrypts it + using the agent public key. + + - The manager then computes the session key using the premaster + secret and encrypts, among others, its password with the + computed key. + + - The agent decrypts the premaster secret and computes the same + key to decrypt the password. + + - The agent checks with a database (or AAA infrastructures) to + verify the password and then to authenticate the manager. + + Pros and cons + + o is simple to do. But + + +Badra Expires November 27, 2008 [Page 11] + +Internet-Draft NETCONF over TLS May 2008 + + + o It is indeed not easy to convince TLS WG to add password + authentication extension to TLS. + + 3. Running BEEP over TLS: + ---------------------- + + It looks complex for a solution, requires that all implementations + do actually support BEEP. + + 4. Extending NETCONF with a message to start TLS: + ---------------------------------------------- + + This option consists of extending NETCONF with a new message to + start the TLS negotiation and to perform an authentication + mechanism based on RFC4422 (SASL) or on any similar protocol. + + Pros and cons + + o simple to do. But + + o might raise questions from the security ADs; NETCONF assumes + the authentication is part of the transport not NETCONF. + Moreover, it adds complexity related to the use of SASL + PLAIN. + + 5. Enable SSH (RFC4742 and TLS (as defined through this document: + -------------------------------------------------------------- + + Since SSH already defines a password-based authentication and + because this protocol MUST be implemented as a security protocol + for NETCONF, users can rely on SSH for password authentication, and + on TLS for authentication using PSK or certificates. This means the + agent SHOULD passively listen for the incoming SSH (respectively + TLS) connection on port 830 (respectively port ). + + Pros and cons + + o simple to do. + + o already specified by RFC4742 and by the current document. + +B.1. Working Group discussion at the 71st IETF meeting + + Some of the options have been found as not practical in the WG + session during 71st meeting. + + Options #2 and #3 have not been supported in the WG session. + + +Badra Expires November 27, 2008 [Page 12] + +Internet-Draft NETCONF over TLS May 2008 + + + Option #1 and # 4 seems to be against the security design for + NETCONF. Whether #5 or other options can be accepted by the WG + members needs to be discussed on the mailing list. + +Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, May 2008. + + [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. + + [I-D.ietf-netconf-notification] + Chisholm, S. and H. Trevino, "NETCONF Event Notifications", + draft-ietf-netconf-notification-12.txt, (work in progress), + February 2008. + + + + + +Badra Expires November 27, 2008 [Page 13] + +Internet-Draft NETCONF over TLS May 2008 + + +Authors' Addresses + + Mohamad Badra + LIMOS Laboratory - UMR6158, CNRS + France + + Email: badra@isima.fr + +Contributors + + Ibrahim Hajjeh + INEOVATION + France + + Email: hajjeh@ineovation.com + +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 + 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 + + +Badra Expires November 27, 2008 [Page 14] + +Internet-Draft NETCONF over TLS May 2008 + + + 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 November 27, 2008 [Page 15] + -- cgit v1.2.1