The IETF rules met the objective that the IESG had when they proposed them - to
make sure that at least we did not continue to invent yet more protocols that
only support password authentication in the clear.
In the case of HTTP, the DIGEST proposal came within a week of BASIC. If the
IESG rulling had been in place at the time we could have strangled BASIC at
birth and exorcised it from the spec.
Instead the people behind BASIC rather liked it because you could simply plug
your Web server into your existing UNIX password file which at the time was
considered (by them) to be acceptably secure. Don't mind the fact that moving
passwords over the Internet is a rather different proposition to moving them
over a LAN. Don't mind the fact that even UNIX administrators were finally
starting to get the message that they should be using shadow passwords, that
the UNIX password algorithm was no longer acceptably secure in the era of Crack.
So BASIC went into the core HTTP specification and DIGEST did not. DIGEST would
not have emerged as an RFC at all except for the fact that support for an
acceptably secure authentication mechanism was now an IESG requirement to get
to DRAFT status.
If I had got my way in 1993 the whole problem of bank credential phishing might
have turned out rather different - if that is we had managed to get DIGEST
implemented in HTML as well.
At this point I would not suggest that we require protocols to support strong
authentication. In fact I would sugges we require the NOT to.
Instead I would like to see a requirement that an application protocol support
a framework such as OpenID, WS-* or SAML which allows the authentication
problem to be broken out as a separate service where a range of authentication
technologies can be supported - including smartcard/ smarttoken/ OTP/ local
keypair and if you must username/password are supported.
________________________________
From: Robert Sayre [mailto:sayrer(_at_)gmail(_dot_)com]
Sent: Mon 09/07/2007 11:03 PM
To: Keith Moore
Cc: IETF discussion list
Subject: Re: Updating the rules?
On 7/7/07, Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> wrote:
Also from the draft:
"At least for the strong security requirement of BCP 61 [RFC3365], the
Security Area, with the support of the IESG, has insisted that all
specifications include at least one mandatory-to-implement strong
security mechanism to guarantee universal interoperability."
I do not think this is a factual statement, at least when it comes to
HTTP, which is where my interest lies.
note that it is not necessary to have at least one
mandatory-to-implement strong security mechanism to guarantee
interoperability.
This response sounds suspiciously similar to responses from defenders
of technology and procedures that don't work. That is, the response
assumes that the questioner doesn't understand the finer points of the
system. I'm sure there are details and strategies I don't know about,
but the point about shifting implementation burden is usually one of
the first qualifiers to get dragged out in these arguments. Amusingly,
it sounds pretty pointless in the context of the qualifier that
usually follows: "mandatory-to-implement does not mean
mandatory-to-deploy". This distinction might make sense when
classifying routers and things, but there's no way to tell the
difference for application protocols.
I'm interested in MTI success stories in application protocols.
Anything related to HTTP is right out, because that stuff doesn't
work. Peter mentioned a small success in XMPP, where implementors were
convinced to allow switching from SSL to TLS.
I'm also interested in the reasoning behind the IESG's decision to
allow Atompub to avoid requiring a specific TLS version. That
certainly allows for incompatible conformant implementations. I don't
understand why WGs are not permitted to make similar judgments
regarding other security mechanisms--they usually know more about
their market than the IESG does.
--
Robert Sayre
"I would have written a shorter letter, but I did not have the time."
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf