Subject: Re: [Netconf] 5539bis was Re: Summary of and AIs from the NETCONF Session in IETF #91

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Dec 2014 14:30:04 +0100

On Thu, Nov 13, 2014 at 10:31:15AM +0000, t. petch wrote:
> ----- Original Message -----
> From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
> To: "ext Benoit Claise" <[email-masked]>; "netconf"
> <[email-masked]>
> Sent: Thursday, November 13, 2014 5:07 AM
> Subject: [Netconf] Summary of and AIs from the NETCONF Session in IETF
> #91
> 
> 
> > Hi Benoit, NETCONF WG,
> >
> > below is a summary and action items from the NETCONF WG session on
> November 11, 2014, Honolulu, Hawaii.
> > A short version of this summary will be made available at OPS area
> Wiki soon (at
> http://trac.tools.ietf.org/area/ops/trac/wiki/IETF91summary).
> >
> > - We had approx. 85+ participants in the 2 hour NETCONF session,
> > - We reviewed the status of the WG,
> > - We had a discussion on all 6 chartered documents.
> > - Note takers were: Lada Lhotka and Balazs Lengyel. The Jabber scribe
> was Rolf Winter.
> > Many thanks to the note takers and jabber scribe for volunteering.
> >
> > The session agenda is available at:
> http://www.ietf.org/proceedings/91/agenda/agenda-91-netconf
> > NETCONF co-chairs will ask for a room for 100 for the next meeting.
> >
> > Following are the decisions taken per humming in the NETCONF session.
> > If there is no strong objection we will implement as proposed.
> >
> 
> <snip>
> 
> >
> > Focus on the use of X.509 for TLS (rfc5539bis)
> >    - supported by a large humm
> 
> 
> A clarification - does this mean that we re-title rfc5539bis as being
> only about the use of TLS leaving those wanting other forms of security
> to write their own I-Ds?
>

This document has _always_ been about TLS. I think you proposed to
narrow it down to TLS with mutual X.509 certification and this is what
the hum was about.

/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: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Dec 2014 14:32:01 +0100

On Thu, Nov 13, 2014 at 10:34:15AM +0000, t. petch wrote:
> > Describe algorithm for extracting a user name out of the X509
> attributes
> >    - loud humm in favor
> >
> 
> A clarification - does this mean that this algorithm goes in
> netconf-server?
>

The idea (as far as I understood it) is that NC over TLS provides a
high-level description of the algorithm. The NC server configuration
document will define the YANG objects to configure this.

/js

---

From: Kent Watsen <[email-masked]>
Date: Tue, 9 Dec 2014 02:12:06 +0000

>document will define the YANG objects to configure this.

I didn't articulate clearly enough at the mic about the "what" and
"how", but Juergen agreed so I'm sure not that he's a mindreader  ;)

Anyway, in reflecting on this, I realized what I should've said
is that it should be whatever is needed so that 5539bis has an
Informative (not Normative) reference to server-model.   Again,
this is the necessary because alternate configuration models can
exist, thus it doesn't make sense to me for 5539bis to say that
it can *only* be configured by just the server-model.

My hope is that 5539bis will assert that client-certs are required
and specify that servers must be configurable to know how to extract
a username using the various options (specified, subAltName, DNS,
etc.).   Another option is for 5539bis to have a Normative reference
onto draft-ietf-netmod-snmp-cfg, section 4.1, though that may be too
convoluted for some.

Kent

---

From: t.petch <[email-masked]>
Date: Wed, 10 Dec 2014 15:23:09 +0000

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>; "t.
petch" <[email-masked]>
Cc: "netconf" <[email-masked]>
Sent: Tuesday, December 09, 2014 2:12 AM

<tp>
Yes, and no.  SNMP over TLS requires the client to present a certificate
which must be present in the server's table, and that is it.  No DNS,
AltName etc.  I would want a good reason to move on from that (perhaps
customers have done so).  But that is in RFC6353 and not in snmp-cfg,
which is different in some details.

Also, I don't know where we got to with SSH and certificates, whether or
not that is likely to appear - part of my logic is that putting it in
server-model covers all protocols for the server (but not for the
client) while putting it in 5539bis can cover both client and server
(but only for TLS).

Tom Petch

Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Dec 2014 17:02:37 +0100

On Wed, Dec 10, 2014 at 03:23:09PM +0000, t. petch wrote:

> AltName etc.

I do not think this is correct. The algorithm details how to extract a
name from certificate fields.

> I would want a good reason to move on from that (perhaps

snmp-cfg is yangifying the algorithm defined in RFC 6353, there is no
functional difference.

> client) while putting it in 5539bis can cover both client and server

Lets not make this more complex by putting other protocols on the
table. Fact is that the server has to derive a username for say NACM
to work. The question whether we should go into client config was
discussed at some IETF meeting some time ago and I heard consensus to
not go there.

/js