Re: [Netconf] rfc5539bis

[Juergen Schoenwaelder <[e-mail]>]

Hi,

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

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