Subject: [NGO] FW: 10/18 agenda item - NETCONF WG Rechartering

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 19 Oct 2007 11:45:06 +0200

Badra and all,

Sam Hartman who is one of the Security Area Directors expressed concern
that the NETCONF over TLS charter proposal does not set the requirements
for user authentication. As these issues proved to be problematic in
syslog and isms, we need more clear requirements in order to have the
NETCONF charter approved including this item. Please propose. 

Dan

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Thursday, October 18, 2007 5:31 PM
To: Romascanu, Dan (Dan)
Cc: Internet Engineering Steering Group
Subject: Re: 10/18 agenda item - NETCONF WG Rechartering

Hi.  I am concerned that the TLS charter item is not specific enough to
lead anywhere clear.  In particular, what are the requirements for user
authentication?

_______________________________________________
NGO mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ngo

---

From: [email-masked]
Date: Fri, 19 Oct 2007 17:13:29 +0200 (CEST)

Dear Dan and all,

I think it is not easy to provide a generic solution. Since TLS left that
to the application itself, I wish we have a common text for all network
managment protocols* to identify the clients when TLS is used.

For the moment, what about remplacing the section 3.2 of NETCONF over TLS
with the following text? Please advice...

   If a server authenticates a client using certificate, the server MUST
   validate the certificate and check the client identity. The general
   algorithm described in section 3.1 can be used for the client
   certificate validation. The user identity could be considered to be the
   Common Name field in the X.509 v3 certificate or any of the fields in
   the AlternativeName extension defined in RFC3280. In this latter case,
   defined options include, among others, an Internet electronic mail
   address, a DNS name, an IP address, MAC, or a uniform resource
   identifier (URI) (RFC2459 section 4.2.1.7). Multiple name forms, and
   multiple instances of each name form, may be included.

Best regards,
Badra

* draft-ietf-syslog-transport-tls-10, draft-marinov-isms-tlstm-00.txt and
isms are not clear regarding the client identification.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 21 Oct 2007 13:44:28 +0200

Badra,

At this point we need to provide text in the charter to make the security AD confident that the requirements for dealing with this issue are clear for the Working Group. It is exactly the fact that ISMS and SYSLOG did not do too good a job on this respect that seems to worry Sam Hartman. Can you make a suggestion on this respect? 

Dan

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Friday, October 19, 2007 5:13 PM
> To: Romascanu, Dan (Dan)
> Cc: Mohamad Badra; Â
> Subject: Re: FW: 10/18 agenda item - NETCONF WG Rechartering
> 
> Dear Dan and all,
> 
> I think it is not easy to provide a generic solution. Since 
> TLS left that to the application itself, I wish we have a 
> common text for all network managment protocols* to identify 
> the clients when TLS is used.
> 
> For the moment, what about remplacing the section 3.2 of 
> NETCONF over TLS with the following text? Please advice...
> 
> * draft-ietf-syslog-transport-tls-10, 
> draft-marinov-isms-tlstm-00.txt and isms are not clear 
> regarding the client identification.
> 
> 
> > Badra and all,
> >
> > Sam Hartman who is one of the Security Area Directors expressed 
> > concern that the NETCONF over TLS charter proposal does not set the 
> > requirements for user authentication. As these issues proved to be 
> > problematic in syslog and isms, we need more clear requirements in 
> > order to have the NETCONF charter approved including this 
> item. Please propose.
> >
> > Dan
> >
> >
> >
> >
> >
> > Hi.  I am concerned that the TLS charter item is not 
> specific enough 
> > to lead anywhere clear.  In particular, what are the 
> requirements for 
> > user authentication?
> >
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 21 Oct 2007 14:07:50 +0200

On Sun, Oct 21, 2007 at 01:44:28PM +0200, Romascanu, Dan (Dan) wrote:
 
> At this point we need to provide text in the charter to make the
> security AD confident that the requirements for dealing with this
> issue are clear for the Working Group. It is exactly the fact that
> ISMS and SYSLOG did not do too good a job on this respect that seems
> to worry Sam Hartman.

I just can't let a statement like "did no do too good a job" stand
uncommented. First, ISMS is currently not chartered to work on SNMP
over TLS and hence the WG did not study TLS issues in detail. Second,
SSH client authentication mechanisms are rather clear within ISMS; the
issue ISMS has been struggling with is the notification case where the
asymmetry of SSH client/server authentication has some interesting
effects especially with regard to access control.

That said, I fully agree that we need to do serious engineering to
find similar/aligned ways to provide security and authentication for
management interfaces, at least covering SNMP, SYSLOG, NETCONF and
potentially other protocols. Failure to find a good solution here will
further push people away from actually properly securing these
interfaces.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 21 Oct 2007 14:16:54 +0200

I may have overstated what Sam said, I apologize, no offense was
intended :-) He meant to say I believe that syslog and isms have
encountered a similar set of problems and no good common approach was
designed by now. Looks close to what you are saying, the question is for
me if the NETCONF recharter is the right place for such work. 

Dan

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Sunday, October 21, 2007 2:08 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; [email-masked]; Sam Hartman
> Subject: Re: [NGO] RE: FW:?10/18?agenda?item?-?NETCONF?WG?Rechartering
> 
> I just can't let a statement like "did no do too good a job" 
> stand uncommented. First, ISMS is currently not chartered to 
> work on SNMP over TLS and hence the WG did not study TLS 
> issues in detail. Second, SSH client authentication 
> mechanisms are rather clear within ISMS; the issue ISMS has 
> been struggling with is the notification case where the 
> asymmetry of SSH client/server authentication has some 
> interesting effects especially with regard to access control.
> 
> That said, I fully agree that we need to do serious 
> engineering to find similar/aligned ways to provide security 
> and authentication for management interfaces, at least 
> covering SNMP, SYSLOG, NETCONF and potentially other 
> protocols. Failure to find a good solution here will further 
> push people away from actually properly securing these interfaces.
> 
> /js
> 
> --

---

From: [email-masked]
Date: Sun, 21 Oct 2007 20:45:55 +0200 (CEST)

Dear Dan and all,

Following is a tentative, Comments are welcome..

"It should be possible to transport the Netconf protocol using several
different protocols. Netconf relies on the transport protocol for the
mutual authentication. During the authentication stage, the identity check
of the two communicating endpoints MUST be performed by the transport
protocol before any configuration or state data is sent to or received
from each other."

Regarding the document "Netconf over TLS", I will insert the following
text to meet above requirements:

Within TLS, the server authentication is usually by default using a X.509
certificate. 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 in section 5 of RFC4642.
According to RFC3546, a TLS client MAY include an extension of type
"server_name" in the (extended) client hello to tell a server the name of
the server it is contacting.

If the server authenticates a client using certificate, the server MUST
validate the certificate and check the client identity. The general
algorithm described RFC4642 can be used for the client certificate
validation. The client identity handled through its certificate MUST be
verified and authenticated by the server according to local policy before
any configuration or state data is sent to or received from the server.
The client identity could be considered to be the Common Name field in the
X.509 v3 certificate or any of the fields in the AlternativeName extension
defined in RFC3280. In this latter case, defined options include, among
others, an Internet electronic mail address, a DNS name, an IP address,
MAC, or a uniform resource identifier (URI) (RFC2459 section 4.2.1.7).
Multiple name forms, and multiple instances of each name form, may be
included.

Best regards,
Badra

>
> Badra,
>
> At this point we need to provide text in the charter to make the security
> AD confident that the requirements for dealing with this issue are clear
> for the Working Group. It is exactly the fact that ISMS and SYSLOG did not
> do too good a job on this respect that seems to worry Sam Hartman. Can you
> make a suggestion on this respect?
>
> Dan
>
>
>
>
>
>
>> Cc: Mohamad Badra; �

---

From: Sam Hartman <[email-masked]>
Date: Mon, 22 Oct 2007 08:23:08 -0400

Hi.
I don't think your text really addresses what I'm talking about.

I want to make sure the working group has had a discussion of how
client to server authentication will be performed using netconf over
TLS and I want to make sure that the participants have considered the
implications when they came to consensus on this approach.

For example if you plan to use an approach that uses client
certificates it is important that WG participants understand this
approach will not support passwords.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 22 Oct 2007 08:19:46 -0400

Hi.  I think I may have confused Dan.

My concern about ISMS is not about the ssh work at all.

however before ISMS decided to go down the ssh path, they considered
several options including a TLS option.  One of the problems with that
option is that it was not clear what it meant.  In particular, TLS in
and of itself does not provide a way to use plaintext passwords or to
integrate into radius (*).  If ISMS had gone down the TLS route, they
would have needed to define the problem much more clearly.

Syslog has had a similar discussion.  They wanted to use TLS, but it
was not clear to what extent authentication of client to server was
important.

It seems clear to me that authentication of client to server is
critical for netconf.

(*) ISMS has also worked on RADIUS SSH integration.

---

From: Mohamad Badra <[email-masked]>
Date: Mon, 22 Oct 2007 15:13:59 +0200

> approach will not support passwords.

Dear Sam,

I think the WG participants are aware of the certificates use and that 
this approach will not support passwords, unless a TLS password-based 
authentication or a <request-login> are defined. The issue was partially 
raised during a discussion on the mailing list 
(http://psg.com/lists/netconf/netconf.2007/msg00234.html).

In any case, Netconf doesn't use <request-login> or rpc for password 
authentication. I posted on the Netconf mailing list alike JUNOS 
approach to support passwords: the session is authenticated by the TLS 
protocol, and therefore a <request-login> is used to pass passwords up 
to the netconf layer.

The WG members have different opinions on such an approach: Andy Bierman 
said "this should be handled with a different top-level element
than <rpc>, outside the scope of the NETCONF protocol. The transport 
details should be taken care of before the NETCONF session mechanisms 
(rpc, rpc-reply, notification) are used".

In addition, 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.

Actually, TLS specifies several authentication methods using namely 
certificates, preshared keys, or tokens. The password authentication is 
also possible by using some works in progress such as SRP, Password 
Ciphersuites for TLS, or EAP (e.g. EAP-TTLSv0), etc.

I personally would prefer to don't limit TLS to <request-login> but 
rather to include the <request-login> as a manner allowing the agent to 
signal that authentication is needed in the hello message and to 
exchange more authentication and authorisation data.

IMO, four options are possible for the WG to move forward:

1- TLS with mutual authentication using certificates on each endpoint.
2- TLS with agent based-certificate authentication and <request-login> 
for the manager authentication.
3- TLS with SRP, TLS password ciphersuites, TTLS with agent 
based-certificate authentication manager based-password authentication.
4- All of above options.

As consequence of TLS, the document "Netconf over TLS" with its actual 
version supports options 1 and 3.

Best regards,

-- 
Mohamad Badra
CNRS - LIMOS Laboratory

---

From: Sam Hartman <[email-masked]>
Date: Tue, 23 Oct 2007 13:59:08 -0400

So, my general issue is to make sure that there is adequate review of
how client authentication will be handeled with the TLS transport.

I think we can handle this with a milestone.

Basically what I'd like is for the WG to decide how it approaches
client authentication early Then, write that up with a few paragraphs
of detail and conduct a review with the security community.  Perhaps a
conference call, perhaps a session at an IETF, etc.  This review needs
to happen soon enough in the process that we can make significant
changes.

If we can agree to a milestone for sucha review and get the chairs to
aggree to work with the security community on such a review, I think
the current charter is fine.

As a specific point, I'm uncomfortable with the request-login method.
I'd much rather see RFC 4422 used or something like that than a
solution that only works for plaintext passwords.  If you do want
something like request-login you need to explain why you are different
from protocols like IMAP, LDAP and POP that used to have a
password-only solution but found it inadequate.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 23 Oct 2007 20:11:36 +0200

So what about the following milestone: 

Mar 2008 - Early Review of client authentication approach (for NETCONF
over TLS) with the security community at IETF 71 

It would be useful for the Security Area to designate a Technical
Advisor to work with the WG for this purpose and other security issues. 

Dan

> Sent: Tuesday, October 23, 2007 7:59 PM
> To: Mohamad Badra
> Cc: Romascanu, Dan (Dan); [email-masked]; [email-masked]
> So, my general issue is to make sure that there is adequate 
> review of how client authentication will be handeled with the 
> TLS transport.
> 
> Basically what I'd like is for the WG to decide how it 
> approaches client authentication early Then, write that up 
> with a few paragraphs of detail and conduct a review with the 
> security community.  Perhaps a conference call, perhaps a 
> session at an IETF, etc.  This review needs to happen soon 
> enough in the process that we can make significant changes.
> 
> If we can agree to a milestone for sucha review and get the 
> chairs to aggree to work with the security community on such 
> a review, I think the current charter is fine.
> 
> I'd much rather see RFC 4422 used or something like that than 
> a solution that only works for plaintext passwords.  If you 
> do want something like request-login you need to explain why 
> you are different from protocols like IMAP, LDAP and POP that 
> used to have a password-only solution but found it inadequate.
>

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 24 Oct 2007 09:32:16 +0200

Hello,
I always thought one important reason to introduce TLS for Netconf was to support small devices 
that anyway have a built-in web server management interface. These devices AFAIK usually have 
an administrator user with a password, but usually do not have any certificates about the 
management user (client). So I think userId/Password base authentication of the client is a must.

I don really know how many people use certificate based client authentication. in my practice 
not many.

regards balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]