- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 17 Dec 2014 08:24:34 +0100
- To: Kent Watsen <kwatsen@juniper.net>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 2014-12-17 00:23, Kent Watsen wrote: > > First time poster here, > > I'm a co-author on draft-ietf-netconf-restconf [1], which describes an > HTTP-based protocol that provides a programmatic interface for accessing > data defined in YANG, using the datastores defined in NETCONF. RESTCONF > is squarely in the realm of network management, not general purpose web > apps. Users of RESTCONF will include operators, service providers, and > the like. > > It is our understanding that some target deployments require the use of > client-certificate based authentication. In one instance, it is the > case that the administrators must insert a smart-card containing a TPM > into a reader attached to the station acting as the HTTP client. > > In addition to ClientCertificate, the Basic and Digest auth schemes are > also high on our list, as they are consistent in spirit to NETCONF's SSH > transport's use of passwords. Like NETCONF, RESTCONF requires a secure > transport (e.g. HTTPS), and so even Basic auth is OK. In sum, what > we'd like to put into the RESTCONF draft is something like this: > > Whenever authentication is required, a RESTCONF server will > enumerate supported authentication mechanisms using the > WWW-Authenticate (RFC 7235) response header. For > interoperability, the server MUST advertise at least one of > The following authentication schemes: > > Basic (RFC 2617, section 2) > Digest (RFC 2617, section 3) > ... These two have new specs over in the httpauth WG (<http://trac.tools.ietf.org/wg/httpauth/>) which you may want to track and review (Basic just finished Working Group Last Call). Best regards, Julian
Received on Wednesday, 17 December 2014 07:25:06 UTC