Subject: RE: Last Call: 'Email Submission Between Independent Networks' to BCP

From: "Christian Huitema" <[email-masked]>
Date: Sat, 11 Jun 2005 00:04:43 -0700

> (1) "known weaknesses [citations]"  is significantly different
> from "we don't like it" or "we assert it is bad" or even "we
> don't like things unless  they contain several additional
> layers".  The third of these might be a reasonable statement,
> but would require even more justification because...

Times change. Today, using challenge response mechanisms such as
CRAM-MD5 over un-encrypted channels is not much more secure than sending
password in clear text. If a third party can listen to the challenge and
response, and then mount a dictionary attack.

Steve Bellovin was alluding to the "evil twin" attack on wireless
network. Allow me to elaborate.

The technique allows an attacker to lure unsuspecting travelers to
connect to an un-protected wireless network under the attacker control.
Very often, laptops are programmed to fetch pending e-mail as soon as
they connect to a network. The laptop will try resolve
"mail.example.com", and start a POP3 or IMAP exchange. The attacker
controls the DNS service on the wireless network, and will easily spoof
the server. It will then respond to the connection with a CRAM-MD5
challenge, and harvest the e-mail address of the victim as well as the
answer to the challenge. The attacker is now in a position to obtain the
e-mail and password pair for the victim. The attack lasts a few seconds,
and may not require any particular action by the victim. 

IETF protocols should not endorse the use of unprotected
challenge-response mechanism. They certainly should not lure clients to
accept challenges from unauthenticated servers.

-- Christian Huitema

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Sat, 11 Jun 2005 10:56:50 -0400

Christian,

Thanks.

This is, IMO, _exactly_ the sort of explanation and
recommendation that needs to be turned into an I-D titled
something like "Challenge-response over unprotected channels no
longer adequate" and published as a BCP.    It didn't require
very many paragraphs of explanation, it is quite clear, and it
is hugely more helpful than what end up sounding like personal
authority statements of the "I don't like it so you shouldn't
use it" variety.

It may be just my ignorance, but this does raise, for me, some
additional issues.  Perhaps they should be put on the agenda for
discussion in the Apps Area meeting (assuming on is held) in
Paris, since this impacts not just email but just about every
application we have:

	(1) Given the problem you describe, then the key feature
	of digest-MD5 is not the difference in algorithm, but
	the fact that it uses a privacy layer.  That should
	probably be much more clear than it has been in most of
	the "digest-MD5 is better" discussions.
	
	(2) If the key issue is "be sure you are talking to the
	right server", then one could still use a
	challenge-response mechanism as long as the server were
	properly verified to the client.  Presumably that could
	be accomplished by client possession and verification of
	a server key or by an extra secret and handshake. That
	would presumably be "good enough" unless we also have a
	significant concern about sessions being hijacked once
	they have been properly initiated. I don't know the
	degree to which that is a practical concern (remember
	that SMTP sessions, especially pipelined ones, are
	typically pretty short and that, e.g., IMAP has
	provisions for in-session reverification although I
	believe they are still not intensively used).
	Conversely, if the server identity is not verified, or
	is verified only by the luser's receiving an
	incomprehensible warning message and clicking "accept"
	every time, then even encryption wouldn't seem to help
	much.   

	(3) I may no longer fully understand the implications of
	"dictionary attack" and suspect that at least some
	application writers understand it even less well that I
	do.  But, if my understanding is correct, it seems to me
	that, if passwords or passphrases are readily vunerable
	to dictionary attacks, there are other problems and the
	presence of encryption would pose an inconvenience, not
	an obstacle, for the attacker.  

Is that correct?

    john

--On Saturday, 11 June, 2005 00:04 -0700 Christian Huitema
<[email-masked]> wrote:

> Times change. Today, using challenge response mechanisms such
> as CRAM-MD5 over un-encrypted channels is not much more secure
> than sending password in clear text. If a third party can
> listen to the challenge and response, and then mount a
> dictionary attack.
> 
> Steve Bellovin was alluding to the "evil twin" attack on
> wireless network. Allow me to elaborate.
> 
> The technique allows an attacker to lure unsuspecting
> travelers to connect to an un-protected wireless network under
> the attacker control. Very often, laptops are programmed to
> fetch pending e-mail as soon as they connect to a network. The
> laptop will try resolve "mail.example.com", and start a POP3
> or IMAP exchange. The attacker controls the DNS service on the
> wireless network, and will easily spoof the server. It will
> then respond to the connection with a CRAM-MD5 challenge, and
> harvest the e-mail address of the victim as well as the answer
> to the challenge. The attacker is now in a position to obtain
> the e-mail and password pair for the victim. The attack lasts
> a few seconds, and may not require any particular action by
> the victim. 
> 
> challenge-response mechanism. They certainly should not lure
> clients to accept challenges from unauthenticated servers.
> 
> -- Christian Huitema
>

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Sat, 11 Jun 2005 11:32:09 -0400

> -----Original Message-----
> From: John C Klensin [mailto:[email-masked]] 
> Sent: Saturday, June 11, 2005 10:57 AM
> To: Christian Huitema; Brian E Carpenter; Keith Moore
> Cc: [email-masked]; Dave Crocker; [email-masked]
> Subject: Client and server authentication for email (was: RE: 
> Last Call: 'Email Submission Between Independent Networks' to BCP)

[snip]

> It may be just my ignorance, but this does raise, for me, 
> some additional issues.  Perhaps they should be put on the 
> agenda for discussion in the Apps Area meeting (assuming on 
> is held) in Paris, since this impacts not just email but just 
> about every application we have:

[snip]

An apparea meeting is planned, but due to the change in meeting structure
we've asked to have it scheduled for a one-hour slot on Monday.  Ted and I
are open to having a discussion topic if someone is willing to lead the
discussion.

-Scott-

---

From: John C Klensin <[email-masked]>
Date: Sat, 11 Jun 2005 11:57:44 -0400

Scott,

I'll leave it to you, Ted, and your IESG colleagues to figure
out what priority this has, but it seems to me that this topic
is, at some point, worth some serious discussion.  If the
security community has really concluded that authentication
without encryption is no longer acceptable --and it certainly
sounds that way from the discussions of the last week, put into
context by Christian's explanation-- then we have a task in
front of us to start upgrading or deprecating almost every
application protocol we have, back to and including Telnet.  

Conversely, it seems to me that an alternate recommendation
would be "don't even bother thinking about running applications
on the public Internet except over encrypted tunnels that
provide both privacy and server authentication".  If we are
headed that way, and believe that advice will be followed, then
perhaps the issues and requirements for individual applications
actually get less stringent than what we've been trying to
insist on for the last several years.

My only strong opinions about this are that some serious,
carefully-explained and consensus-based guidance is in order
here and that it should apply, to the extent possible, across
the applications space rather than being developed by picking at
particular sentences in particular proposed-for-standards-track
documents.

And, coming back to my initial note to Sam on the original
thread, I think that, if we propose to impose much stronger
requirements, we need to be careful about explanations and
education, lest the marketplace respond by saying "too hard",
"can't be deployed at plausible cost", "the users will just
click 'yes' when the warnings come up and get irritated in the
process",  or "lousy user experience" and then ignore whatever
recommendations we have made.

best,
     john

--On Saturday, 11 June, 2005 11:32 -0400 Scott Hollenbeck
<[email-masked]> wrote:

> An apparea meeting is planned, but due to the change in
> meeting structure we've asked to have it scheduled for a
> one-hour slot on Monday.  Ted and I are open to having a
> discussion topic if someone is willing to lead the discussion.
> 
> -Scott-
>

---

From: Dave Crocker <[email-masked]>
Date: Sat, 11 Jun 2005 09:47:30 -0700

>  Times change. Today, using challenge response mechanisms such as

Indeed, times do change.  

That's why is would be quite nice for the security community to take affirmative 
action and formulate consensus statements about mechanisms that are appropriate 
for particular scenarios.

Having the rest of the community attempt to get its work done, including 
specifing security mechanisms as needed, and then have the security community 
come in and take shots at it, is not the way to run a productive process.

In other words, the issue is not with the truth of your assertions but with the 
timing and place of them.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sun, 12 Jun 2005 10:33:48 +0200

>         every time, then even encryption wouldn't seem to help

Yes. This is why I rise the multimodal general issue (can be check-back 
procedure, parallel exchanges, multichannels, multitechnology, etc.). This 
also goes with a generalised usage of IPv6 (identification of a permanent 
address - I do not think the IPSEC is of interest here as one never knows 
about the real end to end path?).
jfc

---

From: Sam Hartman <[email-masked]>
Date: Sun, 12 Jun 2005 07:04:59 -0400

>>>>> "John" == John C Klensin <[email-masked]> writes:

    John> Scott, I'll leave it to you, Ted, and your IESG colleagues
    John> to figure out what priority this has, but it seems to me
    John> that this topic is, at some point, worth some serious
    John> discussion.  If the security community has really concluded
    John> that authentication without encryption is no longer
    John> acceptable --and it certainly sounds that way from the
    John> discussions of the last week, put into context by
    John> Christian's explanation-- then we have a task in front of us
    John> to start upgrading or deprecating almost every application
    John> protocol we have, back to and including Telnet.

I think most of the application protocols are already upgraded
including telnet.  Certainly, LDAP, IMAP, SMTP,XMPP, POP, ftp all work
reasonably well and support binding of authentication to encryption.
I've deployed all of these with the exception of pop in what I believe
to be a secure manner.  SIP and related protocols are also securely
designed but for a variety of reasons take a different approach than
most of the applications protocols.

I agree this is an important topic to discuss.  My personal guess is
that we're doing a fairly good job of protocol design, but that the
deployment of security still lags behind.  Cram-md5 is in fact widely
deployed.  There are some real problems that make digest-md5 and
cram-md5 hard to deploy; this is true for things even more secure than
digest-md5 as well.  I think we're at a point today where we can
describe the problem to people and tell them they should be using
mechanisms that bind authentication to integrity protection.  However
until the security community gets done with a more compelling case for
some of the deployment issues and until vendors pick actually
implement this, I don't think we can go for the sort of mass
deprecation that your mail might contemplate.

Also, I deeply regret the fact that my earlier mail came across as
personal assertion.  I was (and still am) hurried and trying to dig
myself out from under a huge mail backlog.  I wish that I had a chance
to write something more useful.

---

From: avijit mallick <[email-masked]>
Date: Sun, 12 Jun 2005 18:11:21 +0100 (BST)

Sam Hartman <[email-masked]> wrote:>>>>> "John" == John C Klensin writes:

Send instant messages to your online friends http://uk.messenger.yahoo.com

---

From: Dave Crocker <[email-masked]>
Date: Sun, 12 Jun 2005 10:46:59 -0700

>  personal assertion.  

To the likely extent that you think that because my response sounded as if 
that's what I thought, let me a) apologize for that, and b) emphasize that my 
irritation is with the amorphous security community, not with individuals, and 
particularly not with the substance of your statements.

It is the nature of things that those who make the effort to dive into the 
discussion attract the reaction.  I actually greatly appreciate that you are 
doing the diving, even as I express frustrations.  

Those developing functional protocols are universally interested in having good 
security.  There often is a legitimate debate about what is necessary and 
sufficient for a particular function, since usages vary enormously in terms of 
real-world threats.  (By the way, the recent trend to have security folks 
pressure functional folks to first elucidate expected threats strikes me as an 
aid big enough to be paradigmatic.)  

The problem is that a) of course the security folks cannot do all the security 
development, but b) they have almost entirely failed to provide the rest of us 
with the tools and guidance we need.  Pure "education" about security issues is 
not enough.  We need things that are much more applied.

So we are left flailing on our own, and then get late-stage criticisms after we 
have put in considerable effort.

Perhaps the single biggest benefit of having the Security Area produce some BCPs 
is to for the security community to formulate community consensus explicitly.

  d/
  ---
  Dave Crocker

---

From: Keith Moore <[email-masked]>
Date: Sun, 12 Jun 2005 14:41:15 -0400

> not enough.  We need things that are much more applied.

Dave,

I think this begs the question of whether currently known and  
deployable security technologies are actually adequate to the task of  
securing our networks and networked protocols.  I don't mean this to  
sound flippant, but it's not clear to me that they are adequate.

If nothing else, it seems that the diverse and growing set of threats  
in the Internet environment, coupled with exponential increases in  
CPU speed per unit cost, force us to teeter on the "bleeding edge" of  
security technologies - with most users and providers unable to stay  
balanced on that edge and falling victim to frequent attack.

At any rate, the problem might not be so much a lack of easy-to-use  
tools and guidance as a lack of technology.

Keith

---

From: Dave Crocker <[email-masked]>
Date: Sun, 12 Jun 2005 12:21:01 -0700

>  securing our networks and networked protocols.

well, yes, it quite explicitly begs to have such questions discussed, but in 
their own forum and before Last Call for functions that use them, rather than 
after.

  d/
  ---
  Dave Crocker

---

From: Keith Moore <[email-masked]>
Date: Sun, 12 Jun 2005 16:08:54 -0400

>> deployable security technologies are actually adequate to the task  
>> of securing our networks and networked protocols.
>
> well, yes, it quite explicitly begs to have such questions  
> discussed, but in their own forum and before Last Call for  
> functions that use them, rather than after.

Well of course we'd like to understand such questions as early as  
possible.  But that problem is hardly limited to security issues.

There's a real conflict here that we keep dancing around - whose job  
is it to determine the requirements for a protocol design?

It's certainly understandable that WGs and individual submitters  
don't want to be surprised at the last minute by requirements that  
they didn't anticipate.  But often this is because the WG or  
individual submitters did not really try to investigate or ameliorate  
the implications of what they were proposing.  And on at least a few  
occasions a WG or individual has ignored or disregarded information  
about such implications, apparently because it was easier to ignore  
the problem and hope it would be overlooked by IESG than to actually  
understand and solve it.

I don't think this is quite an either-or situation.  We as a  
community certainly need to keep increasing our collective  
understanding of what it means to do good protocol engineering.  But  
it is also incumbent on WGs (and individual submitters) to make sure  
that they have done due diligence in their protocol designs to  
understand the implications of those designs, rather than to place  
the burden on others to explain every possible risk to each WG.   We  
also need to give WGs earlier feedback so that they can fix problems  
that they don't discover before they've made a significant investment  
in the solution.  Neither of these will prevent late surprises, but  
together they should reduce the frequency of such surprises.  And a  
WG that anticipates the problems that might be caused by its proposal  
will be in a better position to reduce the effects of those problems,  
and perhaps provide an upgrade path for when a better solution is  
found, even the problems cannot be entirely solved.

Keith

---

From: John C Klensin <[email-masked]>
Date: Sun, 12 Jun 2005 20:51:03 -0400

--On Sunday, June 12, 2005 4:08 PM -0400 Keith Moore 
<[email-masked]> wrote:

>>>  I think this begs the question of whether currently known
>>>  and   deployable security technologies are actually
>>> adequate to the task   of securing our networks and
>>> networked protocols.
>>
> Well of course we'd like to understand such questions as early
> as  possible.  But that problem is hardly limited to security
> issues.
>
> There's a real conflict here that we keep dancing around -
> whose job  is it to determine the requirements for a protocol
> design?
>...

Keith,

One can try to make a general, and unsolvable, issue out of 
this.  One can also look at a narrower question, and I think it 
is that question that has me (and Dave) concerned.

Let's suppose we have a standards track document that says "this 
is a technique that can reasonably used in situation X".  Maybe, 
to create the problem of interest, it is sufficient that it be a 
standards track document and not say "doing this in any form is 
really stupid but, if you insist on doing it, this is the 
agreed-upon way".

Now someone comes along with another protocol or BCP that is 
being designed.   We claim we believe in reuse of protocols, 
rather than adopting a "invent everything anew" approach, so 
looking for existing tools and protocols is presumably a 
reasonable thing to do.   I'd like to think that, if a group 
finds a standards-track document, checks the various indices and 
determines that it hasn't been superceded or moved off the 
standards track, and decides on that basis to go use the thing, 
they have done due diligence.  If "still on standards track" 
isn't sufficient to constitute a "safe to use" recommendation, 
then I suggest that the IETF is in rather serious trouble.  In 
particular, if someone, especially the IESG, shows up during 
Last Call and says "use of that thing is evil, please drop it", 
that is a symptom of a particularly nasty problem.

There are all sorts of other cases where the problems are lots 
different and it appears clear that insufficient attention was 
paid to existing standards and norms of protocol design.  My 
recent appeal about the MMS conversion document identifies 
several examples.  But, here, it seems to me that we have a 
systemic failure in that, when the conclusion was reached the 
CRAM-MD5 was no long appropriate for use, that conclusion didn't 
lead directly and in short order to an applicability statement 
that said, approximately, "don't depend on that thing" and took 
it off the standard track.

If that had been done, and the authors of the "Email submission" 
document had recommended it anyway, we would be having a rather 
different discussion, don't you think?

     john

p.s. For Newtrk/ISD discussion fans, note that, if we had that 
mechanism in place, the amount of work that would be required to 
deprecate CRAM-MD5 as described above would have been to get 
some level of consensus and reissue the ISD with a "not 
recommended any more" sentence and a change in status for the 
RFC.  The level of flexibility anticipated for those documents 
is such that it would be reasonable to post an version of the 
ISD with that much change and an indication that an explanation 
would follow and/or citations to a few published articles and we 
could reasonably expect to have such a notice posted formally on 
the ISD within a really short time of the IESG decision to 
approve the change.    By contrast, doing it today requires that 
we go though the entire process from I-D to RFC, that the 
description of the problems be complete enough for RFC 
publication, and that there is no real notice to the typical 
implementer until the RFC is published.  Maybe worth a little 
thought.

---

From: Keith Moore <[email-masked]>
Date: Mon, 13 Jun 2005 00:56:30 -0400

> Let's suppose we have a standards track document that says "this is  
> a technique that can reasonably used in situation X".  Maybe, to  
> create the problem of interest, it is sufficient that it be a  
> really stupid but, if you insist on doing it, this is the agreed- 
> upon way".
>
> Now someone comes along with another protocol or BCP that is being  
> designed.   We claim we believe in reuse of protocols, rather than  
> adopting a "invent everything anew" approach, so looking for  
> existing tools and protocols is presumably a reasonable thing to  
> do.   I'd like to think that, if a group finds a standards-track  
> document, checks the various indices and determines that it hasn't  
> been superceded or moved off the standards track, and decides on  
> that basis to go use the thing, they have done due diligence.  If  
> "still on standards track" isn't sufficient to constitute a "safe  
> to use" recommendation, then I suggest that the IETF is in rather  
> serious trouble.  In particular, if someone, especially the IESG,  
> shows up during Last Call and says "use of that thing is evil,  
> please drop it", that is a symptom of a particularly nasty problem.

okay, I see your point.  and for the sake of argument I assume that  
this isn't a case of standard X being contradicted/updated/superseded/ 
invalidated by some later document - the WG or document author has  
read all relevant documents and hasn't found any reason to not use  
standard X.  In such a case I'd certainly support some sort of fast  
track action to publish an applicability statement of the form "X is  
broken and is no longer recommended and considered safe to use; the  
known risks associated with continued use of X are these; we  
recommend that you transition away from use of X (immediately, asap,  
within time T)."

> deprecate CRAM-MD5 as described above would have been to get some  
> level of consensus and reissue the ISD with a "not recommended any  
> more" sentence and a change in status for the RFC.  The level of  
> flexibility anticipated for those documents is such that it would  
> be reasonable to post an version of the ISD with that much change  
> and an indication that an explanation would follow and/or citations  
> to a few published articles and we could reasonably expect to have  
> such a notice posted formally on the ISD within a really short time  
> of the IESG decision to approve the change.    By contrast, doing  
> it today requires that we go though the entire process from I-D to  
> RFC, that the description of the problems be complete enough for  
> RFC publication, and that there is no real notice to the typical  
> implementer until the RFC is published.

well the RFC Editor does have errata pages now.  this might be a good  
use for them, until such time as corrective RFCs can be written and  
published.

Keith

---

From: John C Klensin <[email-masked]>
Date: Mon, 13 Jun 2005 04:07:54 -0400

--On Monday, June 13, 2005 12:56 AM -0400 Keith Moore 
<[email-masked]> wrote:

>...
> okay, I see your point.  and for the sake of argument I assume
> that  this isn't a case of standard X being
> contradicted/updated/superseded/ invalidated by some later
> document - the WG or document author has  read all relevant
> documents and hasn't found any reason to not use  standard X.

In this particular case, that assumption is reasonable.  I don't 
know whether the document authors have done such a search, but 
some of the rest of us certainly did.

> In such a case I'd certainly support some sort of fast  track
> action to publish an applicability statement of the form "X is
> broken and is no longer recommended and considered safe to
> use; the  known risks associated with continued use of X are
> these; we  recommend that you transition away from use of X
> (immediately, asap,  within time T)."

And that would be a plausible solution to the present impasse/ 
debate, although, obviously, not as desirable as getting on 
things before the problem manifests itself in a document that 
has advanced far enough to be up for IESG consideration.

>> p.s. For Newtrk/ISD discussion fans, note that, if we had
>> that   mechanism in place, the amount of work that would be
>> required to   deprecate CRAM-MD5 as described above would
>> have been to get some   level of consensus and reissue the
>> ISD with a "not recommended any   more" sentence and a change
>> in status for the RFC.  The level of   flexibility
>> anticipated for those documents is such that it would   be
>> reasonable to post an version of the ISD with that much
>> change   and an indication that an explanation would follow
>> and/or citations   to a few published articles and we could
>> reasonably expect to have   such a notice posted formally on
>> approve the change.    By contrast, doing   it today requires
>> that we go though the entire process from I-D to   RFC, that
>> the description of the problems be complete enough for   RFC
> well the RFC Editor does have errata pages now.  this might be
> a good  use for them, until such time as corrective RFCs can
> be written and  published.

I suggest that, from a process standpoint, if we start 
deprecating standards-track documents/ recommendations by errata 
page, we will be in big trouble... or will need a process and 
bureaucracy equivalent to the IESG for errata page approvals.

       john

---

From: Keith Moore <[email-masked]>
Date: Mon, 13 Jun 2005 08:51:06 -0400

> I suggest that, from a process standpoint, if we start deprecating  
> standards-track documents/ recommendations by errata page, we will  
> be in big trouble... or will need a process and bureaucracy  
> equivalent to the IESG for errata page approvals.

I would stop short of deprecating standards via the errata pages.  At  
most they should say that the applicability of the standard is being  
reconsidered.

However if we find that there are newly discovered risks with using a  
particular security technology, it does seem prudent to associate  
that information with the relevant RFCs, and this would be a resource  
that authors of new documents could consult when deciding which  
technologies to use.

Keith