[http-auth] (mutual auth) possible discussions / call for opinions

[Yutaka OIWA <[e-mail]>]

Dear HTTPAUTH WG attendees,

The following is the list of possible discussion points
that the authors think.
For most of these, the authors currently think that
current specifications are appropriate.
But at the same time, we'd like to have feedback
for these decisions.

Please feel free to send us a feedback and
we'll consider it for improving the drafts for
publication.
Feed-backs can be either to the list or
to be given directly at the meeting.

See you at Dallas!

==== draft-ietf-httpauth-mutual ====

= Section 3.1 =

[P1] Is adoption of RFC5987 OK?

[P2] The encoding is fixed to UTF-8, without any language.
     (justification: it is not an on-line negotiable parameter,
      and the new protocol does not need to consider older
      clients.)

= Section 4: Messages =

[P3] Are the reserved parameter names making sense?

= Section 4.1: 401-INIT =

[P4] The set of pwd-hash parameters for user-DB migrations:
     none, md5, digest-md5, sha1 makes sense?

[P5] reason parameter:
     Are the listed reasons good and complete?

= Section 4.3 401-KEX-S1 =

[P6] Minimum parameter ranges:
  * 80+ bits for session id (sid)
  * 32+ slots for active nonces: nc-max, nc-window
  * 60+ seconds for session key retention

= Section 5: Authentication Realms =

[P7] Are these choices complete?

= Section 7: Host validation (channel binding to TLS) =

[P8] Is adoption of RFC 5929 OK?

[P9] Do we really need tls-unique for general HTTP?
     (It is too complex for actual implementation,
      because authentication life-duration spans
      over multiple HTTP requests and
      multiple TLS connections.)

[P10] Is 256-bit binding sensible for 512-bit-worth
      authentication exchange?
      (with 256-bit TLS certificates)

= Section 10 =

[P11] Two forms of descriptions are given for client state-machines,
      requested by feedback comments.
      Is it necessary to have both? Or, which one makes more sense?

= Section 12.1: Data Syntax =

[P12] We need non-ambiguous enconding of multiple string sets.
      Are definitions of VI(), VS() satisfactory?

= Section 16: IANA Considerations =

[P13] Choice of Requirement specification levels for
      new algorithms: is "RFC required" satisfactory?
      (see RFC 5226 for other choices)

==== draft-ietf-httpauth-mutual-algo ====

[P14] Iteration counts for "PBKDF2" construction:
      nIterPi is defined to be 16384.  Is this value reasonable?

==== draft-ietf-httpauth-extension ====

= Section 3: Optional authentication =

[P15] Do we want to migrate to (recently-clarified)
      "WWW-Authenticate with 2XX status" for
      notification of possible optional authentications?

      Current choice (separate header) is more friendly
      to co-exist with Cookie-based authentication,
      because an unknown new header will always be ignored.

= Section 4: General issues =

[P16] Length of parameter names:
      Some requests are there, that we should shorten
      name of parameters: how far we should go?
      "logout-URL" or "unauth-URL" might be one level of possible solution.

= Section 4.6 =

[P17] Is it reasonable to use logout-timeout=0 for logout request?
      Or, something more explicit like "request-logout=true" is preferred?

= Section 7: IANA registration =

[P18] Choice of Requirement specification levels for
      new parameters:

      For this specification, we want a weaker-level
      of requirement than the Mutual spec, because
      this spec is intended as general, possibly ad-hoc
      extension points for HTTP authentications.

      Our choice is "Specification Required".
      Is it OK? (See RFC 5226 for other choices, again.)

-- 
Yutaka OIWA, Ph.D.
           Senior Researcher, Research Institute for Secure Systems (RISEC)
    National Institute of Advanced Industrial Science and Technology (AIST)
                      Mail addresses: <[e-mail]>, <[e-mail]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]