Re: [Netconf] rfc5539bis > - NC over TLS with mutual X.509 authentication

[t.petch <[e-mail]>]

----- Original Message -----
From: "Juergen Schoenwaelder" <[e-mail]>
To: "t. petch" <[e-mail]>
Cc: "Kent Watsen" <[e-mail]>; <[e-mail]>
Sent: Monday, October 27, 2014 2:55 PM
>
> the editor does not understand the edits since I do not see clear
> agreement of the scope of the document and thus there won't be a new
> version before the cutoff. It makes a major difference to me
> whether the document is
>
> - NC over TLS with mutual X.509 authentication
>
> or
>
> - NC over TLS plus a structure to plug in new authentication
>   mechanisms

I think that limiting this I-D to mutual X.509 authentication resolves
the issues that have been raised.

Juergen commented on the mix of MAY, MUST etc causing confusion and that
becomes simpler when there is just one approach to be specified.

Martin commented on not knowing what to do about other forms of
authentication - well, keep them out of this I-D and let anyone who
wants to produce a separate I-D thereon.  After all, the specification
of TLS, and of SSH, is littered with I-Ds adding new forms of
authentication so that would be nothing new.

Tom Petch


> and it is not clear whether
>
> - we details the algorithm to extract a username out of an X.509
>   certificate in this spec
>
> or
>
> - leave it to the server configuration model.
>
> If fact, we would be duplicating some elements from RFC 6353 and the
> reusable YANG grouping is in draft-ietf-netmod-snmp-cfg-08 (yes, an
> interesting dependency chain results from that).
>
> I think the WG needs to sort out what set of documents is wanted
> before making further edits.
>
> /js
>
> On Thu, Oct 23, 2014 at 10:04:00AM +0100, t. petch wrote:
> > ---- Original Message -----
> > From: "Kent Watsen" <[e-mail]>
> > To: "Juergen Schoenwaelder" <[e-mail]>;
"t.
> > petch" <[e-mail]>
> > Cc: <[e-mail]>
> > Sent: Wednesday, October 22, 2014 7:29 PM
> >
> > >RFC 5539 has used X.509 certificates and nobody seems to request
any
> > >changes. Why do you make this complicated?
> > >
> > >Yes, NC access control is different from SNMP access control but
this
> > >is irrelevant. All the transport has to deliver is a user name. Why
do
> > >we have to make this complicated?
> >
> > I kind of agree with both sides.
> >
> > On one hand, 5539bis-06 clearly intends to define mutual
> > certificate-based
> > authentication - just search for the word "mutual".  Additionally,
> > Juergen
> > already explained that he put PSK in (-02, according to the change
log )
> > to support NETCONF-light, and since took it out.  So we're
essentially
> > back to just trying to clean up 5539 and make it be in-line with
NETCONF
> > 1.1.
> >
> > On the other hand, there are a couple issues with 5539bis-06:
> >
> > 1) section 2.4.2 (Client Identity) doesn't actually say that
> > certificate-based authentication is required.  For instance, this
text
> > from RFC5539 was left out: "with certificate-based authentication
> > according to local policy"
> >
> > 2) I'm confused by these seemingly conflicting statements:
> >
> >   - section 2.4 (X.509-based Authentication...) says
"Implementations
> > MAY
> > optionally
> >     support TLS certificate-based authentication"
> >   - section 2.5 (Cipher Suites) says "However, implementations MUST
> > support TLS 1.2".
> >
> > So, to Juergen's point, I don't think this needs to be complicated,
but
> > I
> > do think we need to be methodical about ensuring the text says what
we
> > want it to say.
> >
> > <tp>
> >
> > Kent
> >
> > This is what I keep saying or at least, try to say - not sure how
clear
> > I am being.  But until those loose ends of text are removed, then
> > 5539bis remains ambiguous IMHO (and I then remain reluctant to move
on
> > to other issues and other I-Ds).
> >
> > I would go slightly further and change the title and Intro.  Martin
> > raised the point about this I-D seeming to exclude other forms of
> > authentication with TLS so I would entitle this one
> >
> > " Using the NETCONF Protocol over Transport Layer Security (TLS)
with
> > X.509 Certificates"
> >
> > Then anyone is free to write another I-D entitled
> > " Using the NETCONF Protocol over Transport Layer Security (TLS)
with
> > PAKE"
> > or
> > " Using the NETCONF Protocol over Transport Layer Security (TLS)
with
> > PSK"
> > etc etc
> >
> > That leaves us free to be as 'MUST' as we like about authentication,
> > because our use case is simple.
> >
> > I want to see a fresh I-D along these lines - but see below ...
> >
> > </tp>
> >
> > One last point, I'm opposed to 5539bis using
> > draft-ietf-netconf-server-model as a Normative Reference.  I believe
> > that
> > 5539bis should define the protocol on its own, and view
> > draft-ietf-netconf-server-model as just one data-model that could
> > configure it.  FWIW, neither 6242 nor draft-ietf-netconf-call-home
have
> > a
> > Normative Reference draft-ietf-netconf-server-model.
> >
> > <tp>
> > suive ... There is another issue in here.  RFC6241 mandates
> > "The authentication process MUST result in an authenticated client
> > identity whose permissions are known to the server."
> > which suggests we should say something about how. 5539bis did have
text
> > about this but that is now in server-model.  Which sort of leads to
> > having a normative dependency of 5539bis on server-model, not for
> > configuration reasons but for the algorithm used to extract an
> > authenticated client identity from what information the server has
> > gotten..
> >
> > But I do see this as a separate, more debatable issue, to be
discussed
> > once there is clarity in the published I-D about the use of
> > certificates.  And I do think that the document structure is right,
that
> > is, how to extract the identity does belong in server-model and not
in
> > TLS or SSH or other transport I-Ds.
> >
> > Tom Petch
> >
> > Thanks,
> > Kent
> >
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>