[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Last Call: The resolution of ISAKMP with Oakley to Proposed Standard
Douglas, Mark, Jeff, and Mark,
In draft-ietf-ipsec-isakmp-07.txt, there is some some seriously
misleading information in the initial discussion of strong and weak
authentication. I've included a reworded paragraph that corrects
this problem. Here's the offending paragraph:
| 1.5 Authentication
|
| A very important step in establishing secure network communications is au-
| thentication of the entity at the other end of the communication. Many
| authentication mechanisms are available. Authentication mechanisms fall
| into two catagories of strength - weak and strong.
| [So far so good, except for "categories"] Passwords are an ex-
| ample of a mechanism that provides weak authentication. ...
This is wrong. Passwords are not a mechanism. They're just
a factor in establishing identity, like stored secret keys, private
keys, fingerprints, or faces. Strong password protocols
exist, and passwords are important for strong network authentication.
Yes, many bad ways to use passwords have been implemented and deployed.
Yes, there's a lot of misinformation about passwords out there.
But let's not propagate more of it.
| ... The reason pass-
| words are considered weak is the fact that most users pick passwords that
| are easy to guess and when used over an unprotected network are easily
| read by network sniffers. ...
This is poorly worded. If you're talking about off-line dictionary
attack on the sniffed messages, strong password methods are immune
to this. There are also good ways to generate large-enough
(for strong methods) passwords with deterministic entropy
that are easily memorized, and for preventing on-line guessing
attacks.
Sending clear-text passwords or keys is a weak mechanism.
Sending passwords or keys in easily decrypted form is weak.
Sending small passwords in a one-way hashed form that permits
eavesdropper dictionary attack is weak.
Password-authenticated key exchange is strong, and
there are at least three ways to do this.
They are all as strong as the more commonly known digital
signature approaches, when properly used, and can provide
added benefits in many applications, due to decreased need
for stored keys or certificates.
As I understand ISAKMP, passwords aren't suitable here
mainly because users are not actively involved in the
authentication process. So the keys have to be stored anyway,
and thus there is no good reason not to use *large* keys.
This makes your condemnation of password-based mechanisms even
more inappropriate.
Here's a suggested rewording of the paragraph:
| 1.5 Authentication
|
| A very important step in establishing secure network communications is au-
| thentication of the entity at the other end of the communication. Many
| authentication mechanisms are available. Authentication mechanisms fall
| into two categories of strength - weak and strong.
| Sending clear-text keys over a network is weak,
| due to the threat of reading them with a network sniffer.
| Sending one-way hashed poorly-chosen keys with low-entropy is
| also weak, due to the added threat of brute-force guessing
| attack on the sniffed messages. Digital signatures [... etc.]
Thanks.
-- David
> The IESG has received a request from the IP Security Protocol Working
> Group to consider the following Internet-Drafts for the status of
> Proposed Standard:
>
> o The resolution of ISAKMP with Oakley
> <draft-ietf-ipsec-isakmp-oakley-03.txt>
> o Internet Security Association and Key Management Protocol (ISAKMP)
> <draft-ietf-ipsec-isakmp-07.txt>
> o The Internet IP Security Domain of Interpretation for ISAKMP
> <draft-ietf-ipsec-ipsec-doi-02.txt>
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send any comments to the
> iesg@ietf.org or ietf@ietf.org mailing lists by March 28, 1997
>
>Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
------------------------------------
David P. Jablon
Integrity Sciences, Inc.
Tel: +1 508 898 9024
http://world.std.com/~dpj/
E-mail: dpj@world.std.com