Subject: support for draft-thomson-httpbis-cant

From: Kent Watsen <[email-masked]>
Date: Tue, 16 Dec 2014 23:23:11 +0000

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)
            ClientCertificate    (RFC XXXX)

The net-net of all this is that RESTCONF needs a normative reference for an HTTP auth schema using client certificates, and draft-thomson-httpbis-cant is the closest to being it.    Please consider promoting draft-thomson-httpbis-cant to a chartered WG document.   If it helps, I would be happy to work with Martin to complete this draft, whatever it takes to get it across the finish line as quickly as possible.

[1] https://tools.ietf.org/html/draft-ietf-netconf-restconf

Thanks,
Kent

---

From: Julian Reschke <[email-masked]>
Date: Wed, 17 Dec 2014 08:24:34 +0100

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:
>
> ...

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