> Assuming that we set "TLS+AUTH=PLAIN" as the "mandatory to implement"
> answer for IESG, I have two questions:
> 1) Can a compliant server implementation be built without TLS support?
> In particular, UW's pre-built imapd binaries do *NOT* have TLS support
> because our lawyers' interpretation of US law is that we may *NOT* legally
> distribute crypto binaries. Similiarly, UNIX Pine binaries also do have
> have TLS support. PC Pine binaries do, but they use the SSPI features in
> the operating system and do not have crypto code themselves.
Your implementation supports TLS, right? I think that's sufficient. The
fact that one particular packaging of it doesn't include TLS
doesn't make the implementation itself incompliant.
> Any IESG requirement which violates law is null and void. That's just
> common sense.
Hardly. This was debated at length in the IETF in the case of IPSEC in IPv6.
The decision then was that the need for security overrode the restrictions
present in any particular jurisdiction. If there's a problem building it in the
US, or France, or whereever, that's unfortunate for the implementors in those
jurisdictions.
> 2) Can a compliant server implementation refuse AUTH=PLAIN for
> administrative reasons?
Of course. Again, mandatory to implement doesn't mean mandatory to use. A site
is free to have any administrative policy they want.
A related question is whether or not an implementation intended to be used for
only such an environment and which therefore doesn't implement TLS or
AUTH=PLAIN is compliant. IMO it isn't, but given that the target environment is
effectively a special profile of IMAP I fail to see what difference this would
make.
> Suppose a site decides that, by policy, Kerberos is the only permitted
> authentication mechanism and that passwords must NEVER be sent to any IMAP
> server.
That would be fine.
> If the answer to both is "yes" (and I sure hope so!!!), then we need to
> have some recommendations as to what should be implemented in addition to
> the so-called "mandatory" ones. I would therefore recommend that clients
> and servers SHOULD implement as many additional authentication mechanisms
> as possible, with particular emphasis on: KERBEROS_V4, GSSAPI, CRAM-MD5,
> DIGEST-MD5. I would also note that failure to implement any of these
> mechanisms may result in loss of interoperability.
Whether or not such a recommendation is appropriate is up to the group.
Ned
