draft-ietf-netconf-tls-05.txt   draft-ietf-netconf-tls-06.txt 
NETCONF Working Group Mohamad Badra NETCONF Working Group Mohamad Badra
Internet Draft LIMOS Laboratory Internet Draft LIMOS Laboratory
Intended status: Standards Track October 17, 2008 Intended status: Standards Track October 22, 2008
NETCONF over Transport Layer Security (TLS) NETCONF over Transport Layer Security (TLS)
draft-ietf-netconf-tls-05.txt draft-ietf-netconf-tls-06.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 31 skipping to change at page 1, line 31
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 April 17, 2009. This Internet-Draft will expire on April 22, 2009.
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 Security (TLS) This document describes how to use the Transport Layer Security (TLS)
skipping to change at page 4, line 7 skipping to change at page 4, line 7
incoming TLS connection on the TCP port <IANA-to-be-assigned>. (Note incoming TLS connection on the TCP port <IANA-to-be-assigned>. (Note
to RFC Editor: please replace <IANA-to-be-assigned> with the IANA- to RFC Editor: please replace <IANA-to-be-assigned> with the IANA-
assigned value, and remove this note). It MUST therefore send the assigned value, and remove this note). It MUST therefore send the
TLS ClientHello to begin the TLS handshake. Once the TLS handshake TLS ClientHello to begin the TLS handshake. Once the TLS handshake
has finished, the client and the server MAY begin to exchange NETCONF has finished, the client and the server MAY begin to exchange NETCONF
data. In particular, the client will send complete XML documents to data. In particular, the client will send complete XML documents to
the server containing <rpc> elements, and the server will respond the server containing <rpc> elements, and the server will respond
with complete XML documents containing <rpc-reply> elements. The with complete XML documents containing <rpc-reply> elements. The
client MAY indicate interest in receiving event notifications from a client MAY indicate interest in receiving event notifications from a
server by creating a subscription to receive event notifications server by creating a subscription to receive event notifications
[RFC5277], in which the server replies to indicate whether the [RFC5277], in which case the server replies to indicate whether the
subscription request was successful and, if it was successful, begins subscription request was successful and, if it was successful, begins
sending the event notifications to the client as the events occur sending the event notifications to the client as the events occur
within the system. within the system.
All NETCONF messages MUST be sent as TLS "application data". It is All NETCONF messages MUST be sent as TLS "application data". It is
possible that multiple NETCONF messages be contained in one TLS possible that multiple NETCONF messages be contained in one TLS
record, or that a NETCONF message be transferred in multiple TLS record, or that a NETCONF message be transferred in multiple TLS
records. records.
Current NETCONF messages don't include a message's length. This Current NETCONF messages don't include a message's length. This
skipping to change at page 5, line 35 skipping to change at page 5, line 35
NOT use any form of the server hostname derived from an NOT use any form of the server hostname derived from an
insecure remote source (e.g., insecure DNS lookup). CNAME insecure remote source (e.g., insecure DNS lookup). CNAME
canonicalization is not done. canonicalization is not done.
- If a subjectAltName extension of type dNSName is present in the - If a subjectAltName extension of type dNSName is present in the
certificate, it MUST be used as the source of the server's certificate, it MUST be used as the source of the server's
identity. identity.
- Matching is case-insensitive. - Matching is case-insensitive.
- A "*" wildcard character MAY be used as the left-most name - A "*" wildcard character MAY be used as the leftmost name
component in the certificate. For example, *.example.com would component in the certificate. For example, *.example.com would
match a.example.com, foo.example.com, etc., but would not match match a.example.com, foo.example.com, etc., but would not match
example.com. example.com.
- If the certificate contains multiple names (e.g., more than one - If the certificate contains multiple names (e.g., more than one
dNSName field), then a match with any one of the fields is dNSName field), then a match with any one of the fields is
considered acceptable. considered acceptable.
If the match fails, the client MUST either ask for explicit user If the match fails, the client MUST either ask for explicit user
confirmation or terminate the connection and indicate the server's confirmation or terminate the connection and indicate the server's
skipping to change at page 6, line 41 skipping to change at page 6, line 41
5. IANA Considerations 5. IANA Considerations
IANA is requested to assign a TCP port number in the "Registered Port IANA is requested to assign a TCP port number in the "Registered Port
Numbers" range with the name "netconf-tls". This port will be the Numbers" range with the name "netconf-tls". This port will be the
default port for NETCONF over TLS, as defined in this document. default port for NETCONF over TLS, as defined in this document.
Registration Contact: Mohamad Badra, badra@isima.fr. Registration Contact: Mohamad Badra, badra@isima.fr.
Transport Protocol: TCP. Transport Protocol: TCP.
Port Number: TBA-by-IANA (if possible, please assign 6513). Port Number: TBA-by-IANA (if possible, please assign 6513).
Broadcast, Multicast or Anycast: Anycast. Broadcast, Multicast or Anycast: No.
Port Name: netconf-tls. Port Name: netconf-tls.
Service Name: netconf. Service Name: netconf.
Reference: draft-ietf-netconf-tls-05. Reference: draft-ietf-netconf-tls-05.
6. Acknowledgments 6. Acknowledgments
A significant amount of the text in Section 3 was lifted from A significant amount of the text in Section 3 was lifted from
[RFC4642]. [RFC4642].
The author would like to acknowledge David Harrington, Miao Fuyou, The author would like to acknowledge David Harrington, Miao Fuyou,
Eric Rescorla, Juergen Schoenwaelder, Simon Josefsson, Olivier Eric Rescorla, Juergen Schoenwaelder, Simon Josefsson, Olivier
Coupelon and the NETCONF mailing list members for their comments on Coupelon, Alfred Hoenes and the NETCONF mailing list members for
the document. The author appreciates also Bert Wijnen, Mehmet Ersue their comments on the document. The author appreciates also Bert
and Dan Romascanu for their efforts on issues resolving discussion, Wijnen, Mehmet Ersue and Dan Romascanu for their efforts on issues
and Charlie Kaufman, Pasi Eronen and Tim Polk for the thorough review resolving discussion, and Charlie Kaufman, Pasi Eronen and Tim Polk
of this document. for the thorough review of this document.
7. References 7. References
7.1. Normative References 7.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
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS) Extensions", and T. Wright, "Transport Layer Security (TLS) Extensions",
 End of changes. 7 change blocks. 
11 lines changed or deleted 11 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/