draft-ietf-netconf-tls-02.txt   draft-ietf-netconf-tls-03.txt 
NETCONF Working Group Mohamad Badra NETCONF Working Group Mohamad Badra
Internet Draft LIMOS Laboratory Internet Draft LIMOS Laboratory
Intended status: Standards Track May 27, 2008 Intended status: Standards Track June 5, 2008
Expires: November 2008 Expires: December 2008
NETCONF over Transport Layer Security (TLS) NETCONF over Transport Layer Security (TLS)
draft-ietf-netconf-tls-02.txt draft-ietf-netconf-tls-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on November 27, 2008. This Internet-Draft will expire on December 5, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
The Network Configuration Protocol (NETCONF) provides mechanisms to The Network Configuration Protocol (NETCONF) provides mechanisms to
install, manipulate, and delete the configuration of network devices. install, manipulate, and delete the configuration of network devices.
This document describes how to use the Transport Layer Protocol (TLS) This document describes how to use the Transport Layer Protocol (TLS)
skipping to change at page 2, line 18 skipping to change at page 2, line 18
1.1. Conventions used in this document.........................3 1.1. Conventions used in this document.........................3
2. NETCONF over TLS...............................................3 2. NETCONF over TLS...............................................3
2.1. Connection Initiation.....................................3 2.1. Connection Initiation.....................................3
2.2. Connection Closure........................................4 2.2. Connection Closure........................................4
3. Endpoint Authentication and Identification.....................4 3. Endpoint Authentication and Identification.....................4
3.1. Server Identity...........................................5 3.1. Server Identity...........................................5
3.2. Client Identity...........................................6 3.2. Client Identity...........................................6
3.3. Password-Based Authentication.............................6 3.3. Password-Based Authentication.............................6
4. Cipher Suite Requirements......................................7 4. Cipher Suite Requirements......................................7
5. Security Considerations........................................7 5. Security Considerations........................................7
6. IANA Considerations............................................7 6. IANA Considerations............................................8
7. Acknowledgments................................................8 7. Acknowledgments................................................8
A. Appendix - Test Vectors for the PSK Derivation Function........9 A. Appendix - Test Vectors for the PSK Derivation Function........9
B. Appendix - Enabling Third Party Authentication using Passwords10 Normative References..............................................9
B.1. Working Group discussion at the 71st IETF meeting........12 Authors' Addresses...............................................10
Normative References.............................................13 Intellectual Property Statement..................................10
Authors' Addresses...............................................14 Disclaimer of Validity...........................................11
Intellectual Property and Copyright Statements...................14
1. Introduction 1. Introduction
The NETCONF protocol [RFC4741] defines a simple mechanism through The NETCONF protocol [RFC4741] defines a simple mechanism through
which a network device can be managed. NETCONF is connection- which a network device can be managed. NETCONF is connection-
oriented, requiring a persistent connection between peers. This oriented, requiring a persistent connection between peers. This
connection must provide reliable, sequenced data delivery, integrity connection must provide reliable, sequenced data delivery, integrity
and confidentiality and peers authentication. This document and confidentiality and peers authentication. This document
describes how to use TLS [RFC4346] to secure NETCONF connections. describes how to use TLS [RFC4346] to secure NETCONF connections.
Throughout this document, the terms "client" and "server" are used to Throughout this document, the terms "client" and "server" are used to
refer to the two ends of the TLS connection. The client actively refer to the two ends of the TLS connection. The client actively
opens the TLS connection, and the server passively listens for the opens the TLS connection, and the server passively listens for the
skipping to change at page 3, line 47 skipping to change at page 3, line 48
The peer acting as the NETCONF manager MUST also act as the TLS 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 client. It MUST connect to the server that passively listens for the
incoming TLS connection on the IANA-to-be-assigned TCP port <TBA>. incoming TLS connection on the IANA-to-be-assigned TCP port <TBA>.
It MUST therefore send the TLS ClientHello to begin the TLS It MUST therefore send the TLS ClientHello to begin the TLS
handshake. Once the TLS handshake has been finished, the client and handshake. Once the TLS handshake has been finished, the client and
the server MAY then send their NETCONF exchanges. In particular, the the server MAY then send their NETCONF exchanges. In particular, the
client will send complete XML documents to the server containing client will send complete XML documents to the server containing
<rpc> elements, and the server will respond with complete XML <rpc> elements, and the server will respond with complete XML
documents containing <rpc-reply> elements. The client MAY indicate documents containing <rpc-reply> elements. The client MAY indicate
interest in receiving event notifications from a NETCONF server by interest in receiving event notifications from a NETCONF server by
creating a subscription to receive event notifications [I-D.ietf-- creating a subscription to receive event notifications [I-D.ietf-
netconf-notification], in which the NETCONF server replies to netconf-notification], in which the NETCONF server replies to
indicate whether the subscription request was successful and, if it indicate whether the subscription request was successful and, if it
was successful, begins sending the event notifications to the NETCONF was successful, begins sending the event notifications to the NETCONF
client as the events occur within the system. All these elements are client as the events occur within the system. All these elements are
encapsulated into TLS records of type "application data". These encapsulated into TLS records of type "application data". These
records are protected using the TLS material keys. records are protected using the TLS material keys.
Current NETCONF messages don't include a message's length. This Current NETCONF messages don't include a message's length. This
document uses consequently the same delimiter sequence defined in document uses consequently the same delimiter sequence defined in
[RFC4742] and therefore the special character sequence, ]]>]]>, to [RFC4742] and therefore the special character sequence, ]]>]]>, to
skipping to change at page 7, line 12 skipping to change at page 7, line 12
ask the user to confirm. For automated scripts, the names could be ask the user to confirm. For automated scripts, the names could be
expected to match. It is highly recommended that implementations set 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 psk_identity_hint to the DNS name of the NETCONF server (i.e.,
the TLS server). the TLS server).
It is RECOMMENDED that users choose different passwords for the It is RECOMMENDED that users choose different passwords for the
different servers they manage. different servers they manage.
Note 1: The NETCONF over TLS implementation need not store the Note 1: The NETCONF over TLS implementation need not store the
password in clear text, but rather can store the value of 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 inner SHA-1, (SHA-1(psk_identity + "Key Pad for Netconf" +
Netconf") + psk_identity_hint)), which could not be used as a password)), which could not be used as a password equivalent for
password equivalent for applications other than NETCONF. Deriving applications other than NETCONF. Deriving the PSK from a password
the PSK from a password is not secure. This construction is used is not secure. This construction is used because it is
because it is anticipated that people will do it anyway. anticipated that people will do it anyway.
Note 2: [RFC4279] defines some conformance requirements for the Note 2: [RFC4279] defines some conformance requirements for the
PSK, for the PSK identity encoding and for the identity hint. The PSK, for the PSK identity encoding and for the identity hint. The
same requirements apply here as well; in particular on the same requirements apply here as well; in particular on the
password. Moreover, the management interface by which the password. Moreover, the management interface by which the
password is provided MUST accept ASCII strings of at least 64 password is provided MUST accept ASCII strings of at least 64
octets and MUST NOT add a null terminator before using them as octets and MUST NOT add a null terminator before using them as
shared secrets. It MUST also accept a HEX encoding of the shared secrets. It MUST also accept a HEX encoding of the
password. The management interface MAY accept other encodings if password. The management interface MAY accept other encodings if
the algorithm for translating the encoding to a binary string is the algorithm for translating the encoding to a binary string is
skipping to change at page 7, line 41 skipping to change at page 7, line 41
A compliant implementation of the protocol specified in this document A compliant implementation of the protocol specified in this document
MUST implement the cipher suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA and MUST implement the cipher suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA and
MAY implement any TLS cipher suite that provides mutual MAY implement any TLS cipher suite that provides mutual
authentication. authentication.
5. Security Considerations 5. Security Considerations
The security considerations described throughout [RFC4346] and The security considerations described throughout [RFC4346] and
[RFC4279] apply here as well. [RFC4279] apply here as well.
This document in its current version doesn't support third party
authentication due to the fact that TLS doesn't specify this way of
authentication and that NETCONF depends on the transport protocol for
the authentication service. If third party authentication is needed,
BEEP or SSH transport can be used.
As with all schemes involving shared keys and passwords, special care As with all schemes involving shared keys and passwords, special care
should be taken to protect the shared values and passwords as well as should be taken to protect the shared values and passwords as well as
to limit their exposure over time. Alternatively, using certificates to limit their exposure over time. Alternatively, using certificates
would provide better protection. would provide better protection.
6. IANA Considerations 6. IANA Considerations
IANA is requested to assign a TCP port number that will be the IANA is requested to assign a TCP port number that will be the
default port for NETCONF over TLS sessions as defined in this default port for NETCONF over TLS sessions as defined in this
document. document.
skipping to change at page 9, line 18 skipping to change at page 9, line 18
have been cross-verified by two independent implementations. An have been cross-verified by two independent implementations. An
implementation that concurs with the results provided in this implementation that concurs with the results provided in this
document should be interoperable with other similar implementations. document should be interoperable with other similar implementations.
password = password password = password
psk_identity = psk_identity psk_identity = psk_identity
psk_identity_hint = psk_identity_hint psk_identity_hint = psk_identity_hint
The inner SHA-1 value (in hex): The inner SHA-1 value (in hex):
inner := SHA-1(password + psk_identity + "Key Pad for Netconf") inner := SHA-1(psk_identity + "Key Pad for Netconf" + password)
== SHA-1("psk_identityKey Pad for Netconfpassword") == SHA-1("psk_identityKey Pad for Netconfpassword")
=> 6d6eeb6a b8d0466b 45245d07 47d86726 b41b868c => 6d6eeb6a b8d0466b 45245d07 47d86726 b41b868c
The outer SHA-1 value (in hex): The outer SHA-1 value (in hex):
outer := SHA-1(inner + psk_identity_hint) outer := SHA-1(inner + psk_identity_hint)
=> 88f3824b 3e5659f5 2d00e959 bacab954 b6540344 => 88f3824b 3e5659f5 2d00e959 bacab954 b6540344
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 <user-login> 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 <request-login> 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 <rpc> tag element:
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<challenge>Password:</challenge>
</rpc-reply>
In which the manager MUST reply with the following:
<rpc>
<request-login>
<challenge-response>password</challenge-response>
</request-login>
</rpc>
The rules to handle this were pretty simple:
- The <request-login> 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).
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
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 <TBA-by-IANA>).
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.
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 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
skipping to change at page 13, line 47 skipping to change at page 10, line 18
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006. December 2006.
[RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF [RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF
Configuration Protocol over Secure Shell (SSH)", RFC 4742, Configuration Protocol over Secure Shell (SSH)", RFC 4742,
December 2006. December 2006.
[I-D.ietf-netconf-notification] [I-D.ietf-netconf-notification]
Chisholm, S. and H. Trevino, "NETCONF Event Notifications", Chisholm, S. and H. Trevino, "NETCONF Event Notifications",
draft-ietf-netconf-notification-12.txt, (work in progress), draft-ietf-netconf-notification-13.txt, (work in progress),
February 2008. May 2008.
Authors' Addresses Authors' Addresses
Mohamad Badra Mohamad Badra
LIMOS Laboratory - UMR6158, CNRS LIMOS Laboratory - UMR6158, CNRS
France France
Email: badra@isima.fr Email: badra@isima.fr
Contributors Contributors
 End of changes. 12 change blocks. 
163 lines changed or deleted 25 lines changed or added

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