RE: ??NETCONF?over?TLS

[Ma Yuzhi <myz@huawei.com>]

Hi,

> > So, adding a <login> rpc to this document is probably a good idea.
> > But do we want to limit TLS usage to using the <login> 
> method?  People 
> > are also using some field in the 'subject' of a client 
> certificate to 
> > get a user name (or other info) which is then mapped to 
> access rights.
> The concern is that not all NETCONF peers can have 
> certificates or vendor-certificates to get a user name and 
> therefore to map to the access rights. The alternative is to 
> establish a TLS session to authenticate the TLS server (the 
> NETCONF agent) and then use a NETCONF-specific mechanism
> (<request-login>) to authenticate the manager.
> 
> Note that TLS can provide mutual authentication at the 
> transport layer using preshared keys. In this case, 
> <request-login> may be used for sending more authorization 
> and authentication information.
> 

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

> -----Original Message-----
> From: owner-netconf@ops.ietf.org 
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of badra@isima.fr
> Sent: Monday, June 18, 2007 12:36 AM
> Subject: Re:??NETCONF?over?TLS
> 
> Dear Martin,
> 
> >
> > I think this is crucial for the TLS transport to work for NETCONF.
> > RFC4741 says in section 2.3:
> >
> >    NETCONF connections must be authenticated.  The 
> transport protocol is
> >    responsible for authentication.
> >
> >    [...]
> >
> >    The authentication process should result in an identity whose
> >    permissions are known to the device.
> >
> > I don't see how this requirement is met with the current draft.
> >
> > So, adding a <login> rpc to this document is probably a good idea.
> > But do we want to limit TLS usage to using the <login> 
> method?  People 
> > are also using some field in the 'subject' of a client 
> certificate to 
> > get a user name (or other info) which is then mapped to 
> access rights.
> 
> TLS is always responsible for authentication. Section 3 of 
> the document explain how peers can examine the certificate 
> presented by an entity in order to determine if it meets 
> their expectations and therefore to identify the entity's permissions.
> 
> The concern is that not all NETCONF peers can have 
> certificates or vendor-certificates to get a user name and 
> therefore to map to the access rights. The alternative is to 
> establish a TLS session to authenticate the TLS server (the 
> NETCONF agent) and then use a NETCONF-specific mechanism
> (<request-login>) to authenticate the manager.
> 
> Note that TLS can provide mutual authentication at the 
> transport layer using preshared keys. In this case, 
> <request-login> may be used for sending more authorization 
> and authentication information.
> 
> In any case, the document doesn't limit TLS usage to using 
> the <login> method.
> 
> 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/>
> 



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