RE: Updating the rules?

["Hallam-Baker, Phillip" <pbaker@xxxxxxxxxxxx>]

Title: Re: Updating the rules?

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@xxxxxxxxx]
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@xxxxxxxxxx> 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf