Perspectives for enabling Third Party Authentication with "NETCONF over TLS"

[Mohamad Badra <badra@isima.fr>]

Dear all,

I think we front the issue of defining correctly a common mechanism to 
enable using an authentication function for the manager via third parties.

There are many ways to move forward with third party authentication. 
Below three of them, sorry for this long mail. Any advice is wellcome...

1- <request-login>:
-------------------

In the past (June 2007), we discussed on the mailing list of the 
authentication function via third parties, and I proposed using alike a 
JUNOS capability: <request-login>. The rules (sent by Phil Shafer 
https://ops.ietf.org/lists/netconf/netconf.2007/msg00244.html) to handle 
this were pretty simple:

- The <request-login> RPC could only be performed if the TLS doesn't 
provide mutual authentication (the manager isn't authenticated),
- No other RPCs could be performed if the manager isn't authenticated.

In the case of TLS without manager authentication, we must leave the 
<request-login> RPC as the only valid RPC (e.g., anything else is an error.)

This proposal received one objection from Andy Bierman 
https://ops.ietf.org/lists/netconf/netconf.2007/msg00252.html

2- A TLS Extension or an Abstraction layer:
-------------------------------------------

Consequently, I edited the document to enable mutual authentication at 
the TLS layer without considering the use case of third party (AAA for 
example). But some comments and recommendation posted to the mailing 
list said that it is "absolutely" required to enable third party 
authentication.

I would like to have the WG reactions before the meeting in order to 
work on:

2.a- extending TLS (if you have some minutes, please look at 
http://tools.ietf.org/id/draft-badra-tls-password-ext-01.txt). In this 
document, alike SASL PLAIN is proposed within TLS. IMO, this requires an 
action to be taken by the TLS WG.

Or

2.b- on using an abstraction layer over TLS such as SASL (with a framing 
protocol that NETCONF sits above is required).

Dave Nilson proposed the following message transition diagram and 
explained: When a connection request is initiated by the manager to the 
managed entity (agent), e.g. via NETCONF, the manager sends the user's 
credential to the agent, which calls into the local AAA client, which in 
turn contacts the AAA server (over the network).  The user's credentials 
are validated at the AAA server, which in turn responds to the AAA 
client with an accept or reject message (over the network).

But he has the following question: Do you think this kind of 
AAA-integration will work in what you are trying to accomplish with 
NETCONF over TLS?

I CCed Charlie and Hannes for more eventual help.


Manager                Agent--PAM--AAA Client                 AAA Server
  |                      |            |                         |
  |--------------------->|            |                         |
  | TLS session estab.   |            |                         |
  |                      |            |                         |
  |--------------------->|            |                         |
  | User credentials     |            |                         |
  |                      |----------->|                         |
  |                      | User cred. |                         |
  |                      |            |                         |
  |                      |            |------------------------>|
  |                      |            |       Access Request    |
  |                      |            |                         |
  |                      |            |<------------------------|
  |                      |            |       Access Accept     |
  |                      |            |                         |
  |                      |<-----------|                         |
  |                      | User is OK |                         |
  |                      |            |                         |
  |<-------------------->|            |                         |
  |  NETCONF Exchanges   |            |                         |



3-Update BEEP:
--------------

I don't know if people want to update BEEP. If then I think it is better 
to update BEEP with the TLS mutual authentication as described in the 
document "NETCONF over TLS". But here we should keep a TCP port for 
BEEP, and a second port which is required to use TLS alone (mutual 
authentication by TLS itself) and to distinguish between them.


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/>