Add.

1 files changed, 809 insertions, 0 deletions

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 <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 [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 <TBA> 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 <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). 
+
+ 
+ 
+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 <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.  
+ 
+ 
+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] 
+