Subject: [Netconf] server-model #18: how to configure trust-anchors for SSH X.509-based client certs?

From: Kent Watsen <[email-masked]>
Date: Mon, 15 Dec 2014 20:16:03 +0000

This issue was discussed in today's virtual interim meeting:

	https://github.com/netconf-wg/server-model/issues/18

The change is already in the -05 update posted last Thursday and fully
described by this check-in:

	https://github.com/netconf-wg/server-model/commit/6a93885b23fcc9d88d4f8d33
363ae084c08fc8ae

Or more simply by:

    +  feature rfc6187 {
    +    description
    +      "The rfc6187 feature indicates that the NETCONF server supports
    +       RFC 6187";
    +    reference
    +      "RFC 6187: X.509v3 Certificates for Secure Shell
Authentication";
    +  }

And:

        +--rw netconf-server
           +--rw ssh {ssh}?
    +         +--rw x509 {rfc6187}?
    +            +--rw trusted-ca-certs
    +            |  +--rw trusted-ca-cert*   binary
    +            +--rw trusted-client-certs
    +               +--rw trusted-client-cert*   binary

Unless there are any objections by 12/19/14, plan is to keep this change
in the draft as is.

PS: this was discussed at IETF 91, but not raised on the list until now

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 15 Dec 2014 23:21:55 +0100

>     +      "RFC 6187: X.509v3 Certificates for Secure Shell

I would prefer a more self-explanatory feature name, e.g.,
ssh-x509-authentication or something like that.

/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: Kent Watsen <[email-masked]>
Date: Thu, 18 Dec 2014 17:07:15 +0000

Hi Juergen,

>ssh-x509-authentication or something like that.

"ssh-x509-certs" would be more accurate, and shorter too.  Other feature
names are:

 * session-options
 * ssh
 * tls
 * listen
 * call-home

They're all pretty small, mostly one word.  I wish "session-options" could
be smaller...

Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 18 Dec 2014 18:48:31 +0100

On Thu, Dec 18, 2014 at 05:07:15PM +0000, Kent Watsen wrote:
> 
> I wish "session-options" could be smaller...
>

Are there implementations that do not have these timeouts? That is,
are there servers that wait forever if a client connects and simply
does nothing?

I understand that making everything optional features is great because
then there is not much left to implement but then if almost everybody
implements a certain feature, it might be easier to simply make things
mandatory.

/js

---

From: Kent Watsen <[email-masked]>
Date: Thu, 18 Dec 2014 21:24:59 +0000

>implements a certain feature, it might be easier to simply make things

So this is what issue #21 is about:
https://github.com/netconf-wg/server-model/issues/21

I agree that it seems that servers would always implement these timeouts
and thus having no if-feature statement would be OK.  It is what I had
originally after all.  But the issue was raise at the IETF 91 meeting and
is now being confirmed on the list (see email with subject "server-model
#21: Add a feature around the global-params section").  So far there has
been no response to that email, though I think you have just now raise
some skepticism towards needing to do it.

Kent

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Dec 2014 14:21:33 -0800

> https://github.com/netconf-wg/server-model/issues/21

The comment cited in the issue tracker does not give a reason
why servers should not have to implement these timeouts.

> some skepticism towards needing to do it.

We should always justify YANG features wrt/ large resource requirement
or related to an optional protocol, etc.  If we do not think it is an
implementation
burden then make it part of the base module.  More importantly, if lack
of implementation can disrupt operations, then it has to be part of the base
module.

In this case, lack of timeouts can disrupt the server if there is a maximum
number of sessions allowed.  Without timeouts, some app can intentionally
or accidentally lock out other apps by using up all the allowed admin sessions.

> Kent

Andy

>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf