RE: Resolving Digest authentication issue

> In most IETF circles, it is believed that "well-administered firewall"
> is a fleeting circumstance: you might have one today, but it's unlikely
> to remain that way for long. It is also believed that the only
> "physically secure network" is one that you make with wirecutters --
> snipping all the cables, and that the specifications for things
> appropriate for those networks aren't the domain of the IETF.

All true. My purpose was to characterize times when someone might reasonably
deploy and use Basic authentication. It's naive to assume that Basic will
not be used, and so having the protocol state "don't do this thing that
everyone does" makes it seem out of touch.

> b) clients MUST support BOTH Digest and basic-with-SSL/TLS
>    servers MUST support one or the other (or both)

This is essentially what I was proposing. I think you are proposing we go
further and add "clients MUST only use Basic when using SSL/TLS". After all,
if a client supports basic with SSL/TLS, then it of course supports Basic
when not using SSL/TLS. But, I think adding additional constraints goes too
far -- what if a different transport security mechanism is introduced,
perhaps as part of IPv6? It would be better to say, "clients MUST only use
Basic over a secure connection", which then gets us back to the definition
of a secure connection.

> I don't have a preference for what the standard should say,
> except that I believe that it's important that users should
> be able to tell whether a client will interoperate with a
> server without having to do some kind of protocol analysis
> to see which options each supports.

The solution is to place the responsibility of supporting as many
authentication schemes as possible on the client. This frees the server to
pick the one that best serves its needs. That's why I like your choice (b),
since clients MUST support Basic and Digest, while servers only must support
one of the two.  This, then, meets the condition of interoperability without
the user needing to do detailed protocol analysis.

- Jim

Received on Friday, 2 November 2001 13:02:02 UTC