Re: NETCONF over TLS

[Mohamad Badra <badra@isima.fr>]

Ma Yuzhi a écrit :
> so, I personally would prefer we use  <request-login> as a new operation
> rather than rpc.
> The <request-login> maybe provide authentication function  via third party
> mechanism.
>
> Yuzhi
Hi Yuzhi,


Let's start with the following. Comments are very welcome..

(The peer acting as NETCONF manager acts also as TLS client.)

Upon the successful run of protocol's standard authentication mechanism 
(e.g. TLS), the agent may submit an authentication request to have more 
authentication and authorization information from the manager. The agent 
begins the authentication process by emitting the <request-login> tag 
element within an <rpc> tag element:

 <rpc-reply message-id="101"
    xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <username>Username:</username>
      <challenge>Password:</challenge>
 </rpc-reply>

To provide the password along with the username, the manager emits the 
following tag sequence:

 <rpc>
    <request-login>
       <username-response>username</username-response>
       <challenge-response>password</challenge-response>
    </request-login>
 </rpc>

The <challenge-response> and <username> tag elements specify 
respectively the manager's password and username.

The <request-login> maybe provide authentication function via third 
party mechanism. Their tag elements contains the username and the 
password that the application provided to an authentication utility such 
as RADIUS.

After receiving the manager's username and password, the agent emits the 
<authentication-response> tag element to indicate whether the 
authentication attempt is successful.

The agent (or the authentication utility) checks its database for a 
match. If a match is found, the authentication attempt succeeds and the 
agent emits the following tag sequence:

  <rpc-reply message-id="101"
     xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <authentication-response>
             <status>success</status>
        </authentication-response>
  </rpc-reply>

If a match is not found or the password is not correct or the 
<request-login> tag element is malformed, the authentication attempt 
fails and the agent emits the following tag sequence:

  <rpc-reply message-id="101"
     xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <authentication-response>
           <status>fail</status>
           <message>error-message</message>
        </authentication-response>
  </rpc-reply>

The error-message string in the <message> tag element explains why the 
authentication attempt failed.

The agent remits the authentication request up to two more times before 
rejecting the authentication attempt and closing the connection.
The agent remits also the <request-login> tag element when the 
<request-login> tag elements emitted by the manager does not enclose a 
<challenge-response> tag element or when the password enclosed in a 
<challenge-response> tag element is incorrect (in the latter case, the 
agent also emits an <authentication-response> tag element enclosing 
child tag elements that indicate the password is incorrect).

P.S. The <request-login> defined here is heavily based on work done by 
Juniper and borrows text from the reference posted by Phil Shafer on the 
mailing list: 
https://www.juniper.net/techpubs/software/junos/junos82/junoscript82-guide/download/junoscript82-guide.pdf

Best regards,
Badra


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>