Subject: NETCONF over TLS

From: Andy Bierman <[email-masked]>
Date: Fri, 15 Jun 2007 06:59:23 -0700

Hi,

I'm not sure if the WG was ever officially asked to comment
on the draft by Mohamad Badra called "NETCONF over TLS".
So I am asking now.

http://www.ietf.org/internet-drafts/draft-badra-tls-netconf-03.txt

Please send comments on this draft and the feature itself
to the WG mailing list.

Are there implementations of this feature (not just this draft)?

Should this work be standardized?

If not, should it be published as Informational or Experimental?

thanks,
Andy

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

---

From: Phil Shafer <[email-masked]>
Date: Fri, 15 Jun 2007 13:38:21 -0400

>Are there implementations of this feature (not just this draft)?

Haven't read the draft, but we've had JUNOScript over SSL/TLS since
2001.  The only difference between this and normal JUNOScript is
an initial RPC that gives a user and password (<request-login>).
We use certificates as host-verification, but didn't go very
far down this path (user certs, etc).

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 15 Jun 2007 20:14:23 +0200

> Are there implementations of this feature (not just this draft)?

I know that early implementations from INRIA were running over TLS
instead of SSH. They then switched over to SSH after I told them that
TLS is a non-defined transport mapping. Not sure what this means; at
least there were people implementing something like NETCONF over TLS.

> If not, should it be published as Informational or Experimental?

I don't care so much about the political implications of this
question. In practice, I believe a NETCONF over TLS mapping has at
least the same changes of implementation and deployment than some of
the other transport we have put on the standards track and hence I
would vote for a fair treatment of all the transports and then in
three-five years we can decide which ones to declare historic when the
others go for Draft Standard.

/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: [email-masked]
Date: Sat, 16 Jun 2007 19:11:40 +0200 (CEST)

Dear Andy,

Thank you for your request to the WG review.

> far down this path (user certs, etc).

You are right, Phil. The draft says:

   When public key is used for authentication, TLS supports three
   authentication modes: authentication of both parties, server
   authentication with an unauthenticated client, and total anonymity.
   User authentication in unauthenticated or authenticated client mode
   is outside the scope of this document. User authentication should be
   handled by either an extension of TLS (such as the TLS Inner
   Application Extension [IATLS]) or an authentication extension of
   NETCONF.

So, the peer acting as the NETCONF agent (acting also as TLS server) may
be configured to authenticate the NETCONF manager at the TLS layer, at the
NETCONF layer, or at both of these two layers.

In last two cases, we need a NETCONF-specific mechanism ofr manager
authentication and therefore an initial RPC is needed to convey the
username and password, as in JUNOScript

I will update the draft consequently, or send a separated document for
<rpc-login> with NETCONF.

>  Phil

Best regard,
Badra

---

From: Phil Shafer <[email-masked]>
Date: Sat, 16 Jun 2007 16:24:59 -0400

><rpc-login> with NETCONF.

Don't make it 'rpc-login', since that implies it's at the <rpc>
layer.  Use <request-login> or something like that.  Heck, even
<login> would be fine.

Also you should specify (if it's not there already) that the
client needs a cert the server recognises, so the client isn't
throwing a password at a third party.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Sat, 16 Jun 2007 18:38:57 -0700

> others go for Draft Standard.

It is not political, but rather the level of peer review and consensus.

However, a non-WG RFC can be published as Proposed Standard with
the consent of the relevant WG, I think.

Perhaps if Badra, Juergen, and others get help from the Security area
on TLS and Security Considerations, publishing an Informational
or Proposed Standard RFC (from the individual submission, with WG approval)
would be possible.

There are some features waiting in line, like partial locks and access control,
and I don't think the priority of new transport mapping work is very high.

In 3 - 5 years (or maybe less), the mappings that are not
being used will be classified as Historic.  Maybe TLS will
become the default instead of SSH someday.  As long as TLS
is implemented in addition to the mandatory SSH mapping,
I don't think interoperability is harmed.

Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 17 Jun 2007 07:41:33 +0200

In-line. 

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andy Bierman
> Sent: Sunday, June 17, 2007 4:39 AM
> To: Netconf (E-mail)
> Subject: Re: NETCONF over TLS
> 
> >> I'm not sure if the WG was ever officially asked to comment on the 
> >> draft by Mohamad Badra called "NETCONF over TLS".
> >> So I am asking now.
> >>
> to the WG 
> >> mailing list.
> However, a non-WG RFC can be published as Proposed Standard 
> with the consent of the relevant WG, I think.

Indeed. This can be done as a AD-sponsored individual submission.
Actually this is what Mohamad requested, with the observation that he is
targeting Informational RFC status. The process is documented in
http://www.ietf.org/IESG/content/ions/ion-ad-sponsoring.html. 

> 
> Perhaps if Badra, Juergen, and others get help from the 
> Security area on TLS and Security Considerations, publishing 
> an Informational or Proposed Standard RFC (from the 
> individual submission, with WG approval) would be possible.

This falls mainly on the AD, as you can see in the ION. This discussions
is part of my verification about the level of interest and the
availability of expert resources, so please everybody express you
opinions on this list. My estimation until now is that there is a
certain level of interest, but this document needs expert reviews from
NETCONF experts and in the security area, so I would like to make sure
that resources are available for these reviews. 

> 
> There are some features waiting in line, like partial locks 
> and access control, and I don't think the priority of new 
> transport mapping work is very high.

It would probably be good to discuss this submission also in the nee BOF
in Chicago, to see how it rates as level of interest relative to the
other NETCONF extension subjects. 

> become the default instead of SSH someday.  As long as TLS is 
> implemented in addition to the mandatory SSH mapping, I don't 
> think interoperability is harmed.

Yes.

Dan

---

From: Eliot Lear <[email-masked]>
Date: Sun, 17 Jun 2007 12:37:36 +0200

> least there were people implementing something like NETCONF over TLS.

NETCONF/BEEP+TLS gets you there, if this is what people want.

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 17 Jun 2007 14:56:58 +0200 (CEST)

> <rpc-login> with NETCONF.

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.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 17 Jun 2007 17:04:43 +0200

> NETCONF/BEEP+TLS gets you there, if this is what people want.

Obviously, the implementors at that time did not want NETCONF/BEEP+TLS
nor NETCONF/SOAP+HTTPS+TLS.

/js

---

From: Eliot Lear <[email-masked]>
Date: Sun, 17 Jun 2007 16:59:36 +0200

Hi,

I think this draft is a mistake.  When you add the "simple framing" used 
in SSH, you end up with something that is only slightly less complex 
than BEEP but with no libraries, and from a performance perspective 
requires a content scan.  Far better to use BEEP which has a byte count.

Hence I do not believe this draft should be published as an experimental 
document (I disapprove of protocols that are "informational" - makes no 
sense to me).

Eliot

---

From: [email-masked]
Date: Sun, 17 Jun 2007 18:36:21 +0200 (CEST)

Dear Martin,

> get a user name (or other info) which is then mapped to access

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

---

From: [email-masked]
Date: Sun, 17 Jun 2007 18:54:02 +0200 (CEST)

Hi Lear,

> When you add the "simple framing" used

I won't make a comparison for the moment between SSH and TLS to defend
this latter but IMHO, all the points you listed above are given in a
fashion way within NETCONF over TLS:

- The document implements the same SSH "simple framing"
- The content scan and byte count should be done at the TLS Record layer.

Best regards,
Badra

---

From: Eliot Lear <[email-masked]>
Date: Sun, 17 Jun 2007 22:20:02 +0200

> - The content scan and byte count should be done at the TLS Record layer.

My point is not to compare your draft to SSH but to BEEP.

---

From: Ma Yuzhi <[email-masked]>
Date: Mon, 18 Jun 2007 15:48:15 +0800

Hi,

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

> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Monday, June 18, 2007 12:36 AM
> Subject: Re:??NETCONF?over?TLS
> 
> Dear Martin,
> 
> >
> > 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
> 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 [email-masked] 
> with the word 'unsubscribe' in a single line as the message text body.

---

From: Mohamad Badra <[email-masked]>
Date: Mon, 18 Jun 2007 13:44:55 +0200

> The <request-login> maybe provide authentication function  via third party
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

---

From: Simon Leinen <[email-masked]>
Date: Mon, 18 Jun 2007 13:46:32 +0200

> throwing a password at a third party.

I think you mean: "...the SERVER needs a cert the CLIENT recognises,
so the client isn't throwing a password at a third party."

If the client had a cert that the server recognises, that might be
useful, but for a different reason: The server could use that cert to
derive user identity or other attributes that it could use to
authorise access to the NETCONF agent (login) and/or to individual
operations.  Then you would not need a NETCONF <login> operation at
all.  NETCONF could then use TLS like it can use SSH or BEEP (it's a
little less clear with SOAP); namely as a provider of user
authentication/identity.

This is also what Martin hinted at in message
<[email-masked]>, I think.
-- 
Simon.

---

From: Mohamad Badra <[email-masked]>
Date: Mon, 18 Jun 2007 14:08:27 +0200

> <[email-masked]>, I think.
Hi Simon,

That's right, but if we want alike JUNOS mechanism or an authentication 
function via third parties, I think we will need to use the 
<request-login>. This is in order to allow to the server to request the 
client's password (the manager). With regard to my last mail, the server 
will continue the authentication process by emitting the <request-login> 
tag element within an <rpc> tag element:

in which the client replies with:

 <rpc>
    <request-login>

Best regards,

-- 
Mohamad Badra
CNRS - LIMOS Laboratory

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 18 Jun 2007 15:47:33 +0200 (CEST)

Hi,

>        <challenge>Password:</challenge>

I don't get this.  Is this the first message the agent sends after a
<hello>?  A spurious <rpc-reply>??

IMO, the agent has to decide if more authentication is needed or not.

For example:

    manager                      agent
    -------                      -----
    <hello>      <--------->     <hello>

    <!-- this is if the manager tries to do an rpc w/o login -->
    <rpc>
      <get/>     ---------->    
    <rpc>           
                 <----------     <rpc-error> authentication-needed

    <rpc>
      <request-login/>   ----->
    </rpc>

and then the agent sends the message you wrote:

     <data>
       <authentication-response xmlns="new ns">
     </data>
   </rpc-reply>

etc.

Maybe the agent can signal that authentication is needed in the hello
message, by including the new capability for 'request-login'.  Then
the manager can do <request-login> directly, if needed.

/martin

---

From: Eliot Lear <[email-masked]>
Date: Mon, 18 Jun 2007 15:58:25 +0200

Mohamad Badra wrote:
> That's right, but if we want alike JUNOS mechanism or an 
> authentication function via third parties, I think we will need to use 
> the <request-login>. This is in order to allow to the server to 
> request the client's password (the manager). With regard to my last 
> mail, the server will continue the authentication process by emitting 
> the <request-login> tag element within an <rpc> tag element:

First, you re-invented the TLS portion of BEEP, and now you are 
reinventing SASL, and you are going to do it far less functionally.  
Have you tried what's there already?

Eliot

---

From: Phil Shafer <[email-masked]>
Date: Mon, 18 Jun 2007 10:28:06 -0400

>so the client isn't throwing a password at a third party."

Yup, my bad.

>little less clear with SOAP); namely as a provider of user

Yup, this is the part (user certs) that we didn't do in JUNOS.

Thanks,
 Phil

---

From: Mohamad Badra <[email-masked]>
Date: Mon, 18 Jun 2007 16:21:43 +0200

> <hello>?  A spurious <rpc-reply>??

This must be sent after the <hello>, but not necessary the first message.

> the manager can do <request-login> directly, if needed.

Agree.

Best regards,

-- 
Mohamad Badra
CNRS - LIMOS Laboratory

---

From: Mohamad Badra <[email-masked]>
Date: Mon, 18 Jun 2007 17:18:37 +0200

Eliot Lear a écrit :
> and you are going to do it far less functionally.

Hi Eliot,

I don't think I re-invent anything, especially the "TLS profile for BEEP".
I proposed to adopt the <request-login> of JUNOS because I estimated 
that people wish a NETCONF-specific authentication mechanism. Maybe I 
misestimated.

Again, I don't want to compare existing solutions to TLS but I think all 
existing security protocols for NETCONF, excepting SSH, rely on TLS and 
require one or more sub-protocols to be implemented.

What the document does propose is simplifying the TLS's use. As to 
<request-login>, almost all existing applications have their specific 
authentication and/or authorization mechanisms.

Between, could you please tell what "far less functionally" does mean?

Best regards,
-- 
Mohamad Badra
CNRS - LIMOS Laboratory

---

From: Eliot Lear <[email-masked]>
Date: Mon, 18 Jun 2007 17:30:17 +0200

> Between, could you please tell what "far less functionally" does mean?

The whole point of SASL is to provide for multiple profiles so that if 
you want to use the GSSAPI or PLAIN or OTP or something else, you can do 
so.  In fact this is a battle we keep fighting *and* losing in network 
management.  Shall we some day plan to have an ISMS equivalent for 
netconf?  I surely hope not.

And of course, you get all of this for free with the BEEP spec.

Eliot

---

From: Andy Bierman <[email-masked]>
Date: Mon, 18 Jun 2007 09:45:33 -0700

> And of course, you get all of this for free with the BEEP spec.

I have heard comments From Juergen that there are several foo-over-TLS
drafts out there, and perhaps one specification for NM-over-TLS
might be better.  I heard concerns about 'vertical silos' from Dave H
along the same lines.  I also respect Eliot's concerns about reinventing
things.

The details are always messier than the "idea".

So, with this new 'special' <request-login> RPC (that creates
a layer violation in itself) the agent needs to send 'operation-failed'
errors for any other RPC received before this one?  A special mode is needed
in the RPC handler, based on, and coupled to, the transport protocol
used to establish the session -- just to support this special RPC method.

Yuch.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 18 Jun 2007 14:32:25 -0400

>used to establish the session -- just to support this special RPC method.

The rules to handle this were pretty simple:

- The <request-login> RPC could only be performed if the session wasn't
  authenicated.
- No other RPCs could be performed if the session wasn't authenicated
- The transport protocol can authenticate the session (internally)

So over ssh, the session is authenticated by the transport protocol,
which calls a function to pass this information up to the netconf layer.

Over ssl/tls, the session starts with no authentication, leaving the
<request-login> RPC as the only valid RPC.  Anything else is an error.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 18 Jun 2007 11:50:31 -0700

> <request-login> RPC as the only valid RPC.  Anything else is an error.

IMO, this should be handled with a different top-level element
than <rpc>, outside the scope of the NETCONF protocol.
That way, no special RPC code is needed at all.
Only sessions that have been properly authenticated, and <hello>
messages are okay, should be allowed to use <rpc> methods.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 18 Jun 2007 15:47:43 -0400

>than <rpc>, outside the scope of the NETCONF protocol.

So is another scenario where the generic RPC mechanism
we defined in NETCONF can't be used?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 18 Jun 2007 12:56:11 -0700

> we defined in NETCONF can't be used?

It is a matter of SHOULD be used rather than CAN be used.
IMO the transport details should be taken care of before
the NETCONF session mechanisms (rpc, rpc-reply, notification)
are used.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 18 Jun 2007 13:02:45 -0700

> we defined in NETCONF can't be used?

My interpretation of the text in RFC 4741, sec. 2.2 and 2.3
is that these transport services must be provided to the NETCONF layer
(meaning <rpc> in this case), and implies that the NETCONF layer
can assume that these services are established before a NETCONF
session is used.  IMO, using the <rpc> layer to establish the session
is not supported, or a good idea.

Andy

---

From: [email-masked]
Date: Mon, 18 Jun 2007 23:46:10 +0200 (CEST)

Dear Andy,

In this case, the mutual authentication must be then established by the
transport layer. Currently, TLS specifies several authentication methods
using namely certificates, preshared keys, and tokens. The password
authentication is also possible by using some works in progress: Password
Ciphersuites for TLS, EAP (e.g. EAP-TTLSv0), etc.

Best regards,
Badra

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 18 Jun 2007 17:20:17 -0400

Hi,

BCP72 identifies TLS as the transport security mechanism of choice
when traffic is over TCP. SSH is recommended for remote login
security, for providing channel-level security directly in the
application.

Netconf is designed to do "network configuration" as a
replacement/supplement to the CLI running over a remote login session.
But when netconf starts to move into notifications and into
monitoring, then I think the argument for remote login gets weaker. 

If netconf is meant for "network configuration", i.e., configuring all
types of nodes in the network, then there are some questions to ask:
1) key distribution is important; do more network nodes already
support TLS (and thus have certificates already distributed) or
already support SSH (and already have SSH-related credentials
distributed?  

2) Will netconf provide application-level security beyond what the
secure transport provides, such as data access controls? If so, will
this be easier using TLS or SSH? What attributes need to be passed up
from the transport security to the application to provide these extra
services? 

3) Which is easier to integrate with AAA protocols, such as RADIUS and
Diameter?

4) and most important, what would the operators use if both SSH and
TLS were
available?

Badra's draft is similar to RFC2818, the informational document for
HTTPS. The Syslog WG has developed a draft for a TLS-based secure
transport, as well, with some differences from RFC2818 based on new
recommendations for TLS processing. Badra has had input from Juergen
S, Miao Fuyo (author of the syslog/tls draft), and myself. The
syslog/tls document has required some updates following security
reviews, and Badra's draft may require some updates as well, but I
think the draft will probably pass security review fairly easily. I
would recommend including a section that describes the threats
addressed by the proposal, and how those threats are mitigated.

My recommendation is to ask Badra to publish the draft as
experimental, and ask Badra to find other people willing to implement
Netconf/TLS as part of the experiment. 

David Harrington
[email-masked] 
[email-masked]
[email-masked]

> Sent: Friday, June 15, 2007 9:59 AM
> To: Netconf (E-mail)
> Subject: NETCONF over TLS
> 
> Hi,
>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 18 Jun 2007 15:58:36 -0700

> Ciphersuites for TLS, EAP (e.g. EAP-TTLSv0), etc.

Whatever the details, they need to be handled outside of the NETCONF session
mechanisms.  Translation: Use some sort of <connect> transaction that is
finished before the session is deemed ready to receive <rpc> PDUs.
(My only objection is to the <rpc> usage).

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 19 Jun 2007 11:03:04 +0200

Hello,
Why do you feel we need a new transport mapping? What would that give us, why is it better then 
SSH and BEEP?
You describe in your document what you intend to do, but please motivate us by stating why is 
this a good idea?
regards Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 19 Jun 2007 11:00:11 +0200

Hello,
Although we should treat all transports as equal and I have no BIG problems with the draft, I 
remember that we had problems with the Beep and SOAP transports as well to get people to review 
and update the transport documents.
Balazs

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 19 Jun 2007 12:17:20 +0200

Looking from the AD perspective I have the same question. 

I would suggest that the NEE BOF includes this document on the agenda of
the meeting in Chicago, so that it can be discussed together with the
other proposals for NETCONF extensions, and the community can provide
feedback about its priority in the context of other work that needs to
be done. 

Dan

> [mailto:[email-masked]] On Behalf Of Balazs Lengyel
> Sent: Tuesday, June 19, 2007 12:00 PM
> To: Netconf (E-mail)
> Although we should treat all transports as equal and I have 
> no BIG problems with the draft, I remember that we had 
> problems with the Beep and SOAP transports as well to get 
> people to review and update the transport documents.
> Balazs
> 
> Andy Bierman wrote:
> 
> and access 
> > control, and I don't think the priority of new transport 
> mapping work 
> > is very high.
> > 
> > Andy
> 
> --

---

From: Mohamad Badra <[email-masked]>
Date: Tue, 19 Jun 2007 13:28:43 +0200

Balazs Lengyel writes:

> Hello,
> Why do you feel we need a new transport mapping? What would that give 
> us, why is it better then SSH and BEEP?
> You describe in your document what you intend to do, but please 
> motivate us by stating why is this a good idea?
> regards Balazs
>

Hi Lengyel,

It is not so easy to make a comparison between available security 
protocols for a specific application and to recommend a single one. It 
is easier to define a model threat for that application and then looking 
for a security solution. It is right that BEEP, SSH and other security 
protocols are able to meet the Netconf security requirements, but TLS 
could be a good alternative; even if other protocols could be able to 
give the same services.

There are several reasons why one might want to do Netconf over TLS, but 
please don't consider them as an XOR to the available solutions. some of 
these reasons:

- People are interesting to adopt TLS to become the unifying transport 
for, especially, SYSLOG, IPFIX, SNMP. And I think it is a good idea to 
do that for Netconf too. One argument is the following text posted out 
by David Harrington: [BCP72 identifies TLS as the transport security 
mechanism of choice when traffic is over TCP. SSH is recommended for 
remote login security, for providing channel-level security directly in 
the application. Netconf is designed to do "network configuration" as a 
replacement/supplement to the CLI running over a remote login session].

- TLS natively integrates key distribution and mutual authentication 
based on certificates, preshared keys, tokens, passwords and other 
credential types. If you are going to distribute vendor-certificates for 
your network's devices, TLS will be able to integrate the PKI use in a 
fashion way.

- TLS can provide a user-based access-control model (RFC 4681) and by 
its design it provides a facility for secure connection closure 
(close_notify alert) as well as a flexible way to encapsulate and 
protect EAP (for OTP, PLAIN, CHAP, etc.), AAA and RADIUS attributes.

- As Juergen Schoenwaelder pointed out, the implementors at that time 
did not want NETCONF/BEEP+TLS nor NETCONF/SOAP+HTTPS+TLS.

Best regards

-- 
Mohamad Badra
CNRS - LIMOS Laboratory

---

From: Mohamad Badra <[email-masked]>
Date: Tue, 19 Jun 2007 13:31:41 +0200

> Netconf/TLS as part of the experiment. 

Dear David,

I don't have any problem with that.
Best regards,
Badra

---

From: Eliot Lear <[email-masked]>
Date: Tue, 19 Jun 2007 13:50:46 +0200

> already support SSH (and already have SSH-related credentials

I think you have to start by asking who is trusting whom and for what?  
Take for instance DOCSIS.  Here the cable modems aren't really all that 
trusted, and yet they receive a configuration.  But they have to trust 
the DOCSIS controller.  If one uses NETCONF over BEEP in this way, then 
the clients don't need to log in at all, but they assuredly want some 
reason to trust their configuration server.  TLS and the X.509 
infrastructure is well suited for this, as it is fairly easy to 
configure a small number of DNs that are signed by well known CAs that 
can be trusted.  And so to answer your question, certainly the CAs are 
more well known than SSH will key pairs will ever be.  That leaves the 
configuring of which DN you want to trust.

Oh and for good measure, a manufacturers cert could be demanded for 
*some* sort of authentication.

> from the transport security to the application to provide these extra

I think an example of what you have in mind would help.  I don't 
immediately see relevance between the difference in secure transport and 
what happens above it.

> 3) Which is easier to integrate with AAA protocols, such as RADIUS and

This is where BEEP does its thing.  You do both TLS *and* SASL, and 
voila: you can mix and match, even, based on deployment needs.

> 4) and most important, what would the operators use if both SSH and

Operators need to answer this question.

> Netconf/TLS as part of the experiment. 

I would first like to understand from Badra why TLS+SASL/BEEP is not 
sufficient?

Eliot

---

From: Phil Shafer <[email-masked]>
Date: Tue, 19 Jun 2007 10:41:58 -0400

>voila: you can mix and match, even, based on deployment needs.

Can we hear from folks with experience with netconf/beep?  I was
an early advocate for beep, but our experience was fairly negative.

For us, the quality of the freely-available implementations, as
well as issues with the spec, were seen as trouble, but the bigger
issue was just the complexity.  Yes, you can read a (decoded) beep
session, but do developers understand what they are looking at
without smoke pouring from their ears?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 19 Jun 2007 07:33:26 -0700

Balazs Lengyel wrote:
> Hello,
> Although we should treat all transports as equal and I have no BIG 
> problems with the draft, I remember that we had problems with the Beep 
> and SOAP transports as well to get people to review and update the 
> transport documents.

This is an important point.
We are still looking for volunteers (who understand the edits)
to take over authorship of the SSH and BEEP transport documents.

We somehow need to document the transport details for supporting notifications.
The update for SSH seems very minor -- there are places where the <rpc>
and/or <rpc-reply> elements are mentioned explicitly, and the <notification>
element also needs to be mentioned.  There are no SSH protocol differences
whatsoever, due to the notification feature.

The BEEP document needs to be reviewed, and updated for notifications.
Clearly the BEEP Profile needs to include the <notification> element,
but there may be other text that needs updating.

The SOAP document would require significant work to support Notifications,
exactly as defined in the draft (e.g., without changes to any of the RPCs).

Of course, the TLS document must support the Notification draft as well.

Notifications is going to be done soon, and transports which do not get
updated to support them will almost certainly be reclassified as Historic.

Andy

---

From: "tom.petch" <[email-masked]>
Date: Tue, 19 Jun 2007 16:04:31 +0200

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "Eliot Lear" <[email-masked]>
Cc: "Mohamad Badra" <[email-masked]>; "Simon Leinen" <[email-masked]>;
<[email-masked]>
Sent: Monday, June 18, 2007 6:45 PM
Subject: Re: NETCONF over TLS

> used to establish the session -- just to support this special RPC method.
My reaction is stronger than that.  There are several warnings around that
working groups should not attempt to design there own security mechanisms.
There are too many pitfalls for those not experienced in the field and we should
not go down that road.

NETCONF allows you to change configurations so strong authentication of the
'manager' is a must.  We need one security mechanism that is a MUST to implement
to ensure interworking.  As others have pointed out, there is a plethora of
existing methods, to which I would add PSK and SRP for TLS, and several RFC
reviewing authentication.  Go choose.

Tom Petch

---

From: Simon Leinen <[email-masked]>
Date: Tue, 19 Jun 2007 17:17:29 +0200

> replacement/supplement to the CLI running over a remote login
> session.  But when netconf starts to move into notifications and
> into monitoring, then I think the argument for remote login gets
> weaker.

One could say that, conversely, the argument for other transport
features (such as multiple channels) gets stronger.  But so far the WG
seems to tend to reduce the transport requirements, viz. the evolution
of the notification mechanism, which now works over a single channel.

> If netconf is meant for "network configuration", i.e., configuring
> all types of nodes in the network, then there are some questions to
> ask: 1) key distribution is important; do more network nodes already

For the environments I'm familiar with ("classical" ISPs):

* Fully manageable nodes support both SSH and TLS; SSH for access to
  the CLI, and TLS for access to the integrated HTTP server.

* Operators often enable SSH but leave TLS disabled, because HTTP is
  not usually used for management in these environments.

> secure transport provides, such as data access controls?

I absolutely expect that at least some NETCONF implementations will
provide facilities to restrict access to certain parts of the
configuration based on user identities.  Some vendors do this today
for CLI-based configuration.

> If so, will this be easier using TLS or SSH? What attributes need to
> be passed up from the transport security to the application to
> provide these extra services?

The systems that I'm familiar with makes these decision based on user
identity (username).  This is readily available with SSH, but usually
not with TLS.

> 3) Which is easier to integrate with AAA protocols, such as RADIUS
> and Diameter?

SSH has been integrated with AAA protocols (RADIUS and TACACS+ in our
case).  I don't know whether this has been done with TLS.

> TLS were available?

The one that's more likely to be widely implemented and that fits
better into their existing AAA infrastructure, I would guess.
-- 
Simon.

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 19 Jun 2007 11:19:15 -0400

Hi,

In the Syslog WG, we debated having a TLS transport draft, since we
already had a syslog over BEEP RFC. The WG is primarily made up of
implementers, and they found very little demand for BEEP from
operators.

Many already know I favor a common secure transport layer for multiple
NM protocols. I think the concept of BEEP is wonderful, since it
**standardizes** secure transport for NM, providing a more secure
environment across NM interfaces, and reducing security configuration
work. But operators seem to refuse to use it, either because the
toolkits that have been available were not good enough, or the
deployment introduces more problems than it solves. 

I do not know how to convince operators to adopt BEEP. I think the
best approach will be to make it available in widely-used products,
and get operators to try out a good solid implementation with solid
support. I believe BEEP is now being shipped in Cisco products, and
new BEEP toolkit implementations are becoming available, so maybe that
will help turn the tide on BEEP deployment.

Until BEEP is accepted by operators, I do not believe we should
disallow a Netconf/TLS transport just because there is a Netconf/BEEP
transport. If BEEP is accepted by operators because it reduces the
work of deploying security for multiple NM protocols, the TLS
transport might just go away.

David Harrington
[email-masked] 
[email-masked]
[email-masked]

> From: Phil Shafer [mailto:[email-masked]] 
> Sent: Tuesday, June 19, 2007 10:42 AM
> To: Eliot Lear
> Cc: David B Harrington; 'Andy Bierman'; 'Netconf (E-mail)'

---

From: Eliot Lear <[email-masked]>
Date: Tue, 19 Jun 2007 17:34:46 +0200

Dave,
> deployment introduces more problems than it solves.

Until recently operators didn't have a choice to even deploy it, so I'd 
not read too much into what operators think right just yet.

> transport might just go away.

But it's not just TLS- it's TLS + User level authentication + framing.  
Guys, that's what BEEP is.

Eliot

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 19 Jun 2007 12:15:47 -0400

Hi Eliot,

> From: Eliot Lear [mailto:[email-masked]] 
> Sent: Tuesday, June 19, 2007 11:35 AM
> To: David B Harrington
> Cc: 'Phil Shafer'; 'Andy Bierman'; 'Netconf (E-mail)'

I understand the sentiment, and maybe we shouldn't put much stock in
what operators have done so far. However, I think operators did have a
choice of multiple syslog implementations that implemented
syslog/BEEP, and weren't sold by that solution. I don't understand why
they will be sold by Netconf/BEEP.
> Guys, that's what BEEP is.

If BEEP is just TLS + SASL + framing, why can't we just use TLS + SASL
+ framing? Where is the value-add for using BEEP instead of using the
independent components? How does BEEP make it easier for an operator
to operate their network than if they simply used TLS + SASL + a
standardized framing approach?

---

From: Andy Bierman <[email-masked]>
Date: Tue, 19 Jun 2007 11:49:11 -0700

> Hi Eliot,

This whole thing is sounding more TLS-specific and
less NETCONF-specific every day.

IMO, the Network Configuration WG is working on a network configuration
protocol.  The optional notifications do not change the focus of the protocol.
Transport and security problems are not the focus of this WG either.

I would rather the WG spend energy on finishing the Notifications draft,
or even discussing access control or data modeling on the NGO list.
Or even better, ignore this email thread altogether because you are
too busy implementing NETCONF to notice ;-)

Andy

---

From: Eliot Lear <[email-masked]>
Date: Wed, 20 Jun 2007 09:27:19 +0200

> standardized framing approach?

I think these are good and fair questions.  First, I didn't say that 
BEEP is *only* that.  BEEP has a couple of what I would call frills, 
like the ability eliminate directionality to ease "call home".  That's 
going to valuable to operators who need to manage hundreds of thousands 
of devices.  Again, think along the lines of DOCSIS.  A management model 
where the manager connects to hundreds of thousands of devices is just a 
non-starter.  In addition, the framing allows interspersing of different 
(presumably related) applications.  This would simplify operator 
access-lists, not to mention AAA operations (one versus N).  SSH offers 
this sort of functionality, as you correctly pointed out elsewhere 
yesterday.

But beyond that, I'd tend to agree with your sentiment.  If you wanted 
to do what I would call a "BEEP light" that does TLS + user login, then 
I implement SASL first, and then a very simple framing protocol that 
NETCONF sits above, particularly one that doesn't require funky tags in 
the data, making parsing a pain.

And so before you start NETCONF you add some gook along the lines of:

C: start-netconf

S: 354-authenticate first
S: 354-SASL/PLAIN
S: 354-SASL/OTP
(...)
S: 354 SASL/GSS-API
C: SASL PLAIN username=foo password=bar
S: 250 OK
C: start-netconf
S: 350 228 greeting follows
<greeting>
...
C: 278
<greeting>
...

(where 228 and 278 are byte counts)

What this gets you is integrated authentication and out of the byte counting
business.  You might even be able to steel the byte count code from either SMTP
CHUNKING or IMAP (although IMAP is a bit weird).

Eliot

Eliot

---

From: Tomoyuki Iijima <[email-masked]>
Date: Thu, 21 Jun 2007 08:57:45 +0900

Hi,

I agree with the following Andy's comment.

> > messages are okay, should be allowed to use <rpc> methods.

NETCONF and TLS are completely separeted mechanism. TLS were
standardized to carry any application/transport protocol. Since
SOAP/BEEP have been chosen as transport protocol of NETCONF, we don't
need to care about TLS over which SOAP/BEEP would run. Additionaly,
TLS's authentication mechanism is described fully in the RFC 2246. So,
NETCONF does not need to care about authentication. It is unnecessary to
publish NETCONF/TLS-like document.

In the following draft, I wrote my view about security in the case of
NETCONF/SOAP.
http://www.ietf.org/internet-drafts/draft-iijima-netconf-soap-implementation-02.txt

4.  Security Consideration

   Security should be considered from 2 angles.  One is transport-level
   security, and the other is message-level security.  Transport-level
   security such as encryption of entire message is left to SSL/TLS.
   However, the message-level security such as partial encryption of
   message or signature should be achieved by other technologies.  To
   fulfill that need, WS-security has been stipulated.

-- 

-- 
Tomoyuki Iijima
Hitachi, Ltd., Central Research Laboratory
1-280, Higashi-koigakubo Kokubunji-shi,
Tokyo 185-8601, Japan
Tel:+81-42-323-1111 ext.3579
Fax:+81-42-327-7868
E-mail:[email-masked]