[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Perspectives for enabling Third Party Authentication with "NETCONF over TLS"
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/>