Subject: Re: draft-ietf-ipsec-ikev2-06.txt

From: David Jablon <[email-masked]>
Date: Tue, 08 Apr 2003 10:46:54 -0400

I agree with recommendation 2(b) with a further suggestion.

At 07:35 AM 4/8/03 +0300, Hugo Krawczyk wrote:
>(2) Issue of key length for the prf: Make sure that the users of ikev2
>provide enough bits to key the prf. 
>This is very simple and requires only the following two editorial changes:
>
> a- [ ... ]
> b- specify that when pre-sharing a key for use in prf-based authentication 
>    (i.e., Shared Secret") this key SHOULD [ be ] of the length of the key for the
>    prf agreed for use by the parties

I recommend adding "and this key SHOULD NOT be derived solely
from a password or other data that has less randomness than a
truly random key of the appropriate length."

>       Note: here I would have preferred to say MUST instead of SHOULD, 
>        but I know that you want to allow the use of passwords in this mode.

I too prefer "MUST", and I prefer "MUST NOT" in the addition.

If this text is meant to allow the shared secret key to be a password,
or to be derived solely from a password, it is insufficient to specify
merely the length of the shared secret.  If not, then MUST and
MUST NOT seem more appropriate.

In any case, the text should at least encourage implementations that
encourage use of a shared secret that has sufficient randomness,
which, in the case of a password, typically requires that the password
be a good amount longer than an equivalent key.

Regarding:

>    We assume that the prf
>    function takes a variable length key and produces a fixed length
>    output. When the key for the prf function has fixed length, its
>    specification for use in IKEv2 must include a procedure for deriving
>    its required fixed length key from a variable length key.
>
>This may be short and elegant but it actually creates a big problem 
>for who wants to use non-HMAC prfs, in particular AES.
>Indeed, AES takes fixed keys only and it has no built-in mechanism to handle
>variable-length keys.  Designing such a mechanism is a very non-trivial
>problem (as those subscribed to the cfrg list have witnessed recently).
>Therefore, your text above while seemingly simplifying the IKE specification
>actually requires to standarize something (variable key support for AES or
>general block ciphers) that can take long to get right technically and even
>longer to get ietf consensus. In contrast, the spedifications on the length 
>of nonces and preshared key, suggested above, are simple to state, and 
>transform the variable key headache into a non-issue.
        
It seems like a tradeoff must be made here.  A prf that takes variable
length input might be seen as useful to accept passphrases that are
a good amount longer than equivalent shared secret keys.  I think the
suggested (amended) text only makes the headache disappear
when shared secrets are keys, and not things like passphrases.

-- David

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 9 Apr 2003 09:47:21 -0700

>I too prefer "MUST", and I prefer "MUST NOT" in the addition.

Could you explain the technical reason for that? If someone uses a 
password instead of a sufficiently-random shared secret, will the PRF 
break?

We have no way of testing if someone has used a password vs. a shared 
secret. If we say MUST and MUST NOT, we are saying that 
implementations must somehow test for this. SHOULD and SHOULD NOT 
(with the appropriate wording about the problems of passwords) seems 
more realistic, but if there truly is a technical problem with using 
a password in a PRF as Hugo has described, then we should know about 
it.

--Paul Hoffman, Director
--VPN Consortium

---

From: Hugo Krawczyk <[email-masked]>
Date: Thu, 10 Apr 2003 02:19:05 +0300 (IDT)

> a password in a PRF as Hugo has described, then we should know about 

Let's answer this serious question with the following real life dialogue.

Doctor: I have some bad news and some very bad news.
Patient: Well, might as well give me the bad news first.
Doctor: The lab called with your test results. They said you have 24 hours
to live.
Patient: 24 HOURS! That's terrible!! WHAT could be WORSE? What's the very
bad news? 
Doctor: I've been trying to reach you since yesterday. 

In our case the bad news is that the prf's strength is now at most as the
entropy of the password (typically < 32 bits).  The weakness here is
obvious: brute force attacks in 2^32 operations.

The worse news is that some prf's may interact particularly bad with short
keys. Think, for example, of an application using 3keys-3DES as the prf
and a specification (as suggested in this list) to pad with 0s to the
whole key length.  If the key is given as an 8-character password then
this is at best (even if the password is totally random) equivalent to
single DES, against which you can use a "conventional" single-DES cracker.

The worst news is that the exchange is open to off-line dictionary attacks
no matter how you derive the key from the password (as long as this
derivation does not use additional secret keys). In particular, this is
the case when you use HMAC with a password.

Hugo

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 9 Apr 2003 16:17:44 -0700

At 4:57 PM -0400 4/9/03, David Jablon wrote:
>I don't really want to debate the point of whether the text should *allow* for
>the use of weakened Shared Secret keys.

It sounds like you do. RFC 2119 has very specific definitions for 
SHOULD, SHOULD NOT, MUST, and MUST NOT. Saying "MUST NOT" has very 
different semantics than "SHOULD NOT do this because it is weak".

I assume you are not proposing that we remove the normative reference 
to RFC 2119. If you are, that's a very different topic...

>   But it seems like the implications
>need to be more clearly stated, and whether an implementation must allow
>for full-strength keys is not addressed in the SHOULD version.
>
>Here's the proposed text in question:
>
>2(b)+:
>         "When pre-sharing a key for use in prf-based authentication
>         (i.e., Shared Secret") this key {SHOULD | MUST} be of the length
>         of the key for the prf agreed for use by the parties, and this key
>         {SHOULD NOT | MUST NOT} be derived solely from a password
>         or other data that has less randomness than a truly random key
>         of the appropriate length."
>
>At 09:47 AM 4/9/03 -0700, Paul Hoffman / VPNC wrote:
>>password instead of a sufficiently-random shared secret, will the 
>>PRF break?
>
>I think that's the wrong question, or at least I don't understand
>how insufficiently random input can "break" a PRF.

I don't either, that's why I asked. "MUST NOT" would indicate that it 
would break something, "SHOULD NOT" would indicate that the the 
something would work but probably not the way one would want.

>But your first question forces me to elaborate my concern over the
>SHOULD version.  Using "SHOULD", the security of an implementation
>may certainly be broken.  And any relevant security proofs or arguments
>that assume that keys are random will certainly not apply.

I have never read a security proof, but if they rely on user-selected 
things like preshared keys to have a particularly amount of 
randomness, then they are not based on reality. No matter what you 
tell them, users will sometimes choose passwords or even non-password 
preshared secrets with less than 112/128 bits of randomness. They 
just will.

We are designing IKEv2 for Internet users, not for people who write 
security proofs. Having said that, I obviously support telling users 
as well as we can what they should do to make their systems secure in 
the way that the security proof says it is. But that is quite 
different than mandating that IKEv2 systems have to check the 
randomness of the preshared key.

>The text in draft 06 states that human-chosen password-derived
>keys are insecure in this context but it doesn't fully explain why.

We should obviously fix that.

>(See proposed change below.)
>Naively replacing key bytes with password bytes results in a
>skewed distribution. Depending on how the password is chosen,
>an N-byte password may have as little as 10% to 20% of the
>randomness of an N-byte key.  Just having the high bit of each
>ASCII password byte set to zero guarantees at least a 12.5% loss.
>
>A good technical reason for saying MUST instead of SHOULD in 2(b)+
>is that SHOULD permits implementations that restrict ALL keys to
>insecure length and/or insufficient randomness.

That is not what RFC 2119 says for the difference between SHOULD and 
MUST. If you want us to redefine the words in RFC 2119, we can, but 
you can't both normatively reference RFC 2119 and use the argument 
above.

>  >We have no way of testing if someone has used a password vs. a 
>shared secret. ...
>
>Now that you mention it, there are surely some easy ways to detect
>common causes for insufficient randomness.  But I wasn't proposing
>such a requirement.

By using "MUST", you are.

>  >... If we say MUST and MUST NOT, we are saying that 
>implementations must somehow test for this. ...
>
>No.  I don't think so.  At least I didn't intend to.
>It does (and should) say something about the design of the mechanism
>for shared secret key entry, and for shared key selection (if any) ---
>namely that they should not force or encourage the use of weakened keys.
>
>>... SHOULD and SHOULD NOT (with the appropriate wording about the 
>>problems of passwords) seems more realistic, but if there truly is 
>>a technical problem with using a password in a PRF as Hugo has 
>>described, then we should know about it.
>
>If we didn't know how passwords are different than keys,
>and how our security assumptions require truly random keys,
>then we should now.
>
>A little more wordsmithing would seem to be needed to fix the
>technical problem with the SHOULD version of 2(b)+.
>Even if weak keys are supported, it seems good to at least
>require that implementations MUST *permit* the use of
>full-strength keys,

Ah, much better! There is an interoperability reason why they MUST: 
some systems designed for people who can't enter passwords if they 
tried will have preshared secrets that are long.

>  and { MUST | SHOULD } *encourage* the
>use of full-strength keys.

Now you are talking about the user interface, which most definitely 
is out of scope for this protocol document. If you want to write an 
implementation guide for IKEv2, this would obviously be appropriate 
there.

>Also, one sentence in draft 06 should be expanded to better
>distinguish the insecure practice from various other secure ways
>of deriving shared secrets from combinations of passwords and keys.
>Here's a suggested expansion:
>
>         "Note that it is a common but [[ typically ]] insecure 
>practice to have a
>         shared key derived [[ solely ]] from a user chosen password[[,
>         without incorporating another source of randomness ]]."

I would leave out the "typically": you simply don't see passwords 
with 112 or 128 bits of randomness. I don't agree with the final 
clause because we can't mandate that IKEv2 systems change the 
password on the user. Instead, you could say "In order to get 
preshared secrets with a sufficient amount of randomness, users 
typically need those preshared secrets supplied by systems that 
compute them."

--Paul Hoffman, Director
--VPN Consortium

---

From: David Jablon <[email-masked]>
Date: Wed, 09 Apr 2003 16:57:33 -0400

Paul,

I don't really want to debate the point of whether the text should *allow* for
the use of weakened Shared Secret keys.  But it seems like the implications
need to be more clearly stated, and whether an implementation must allow
for full-strength keys is not addressed in the SHOULD version.

2(b)+:

At 09:47 AM 4/9/03 -0700, Paul Hoffman / VPNC wrote:
>Could you explain the technical reason for that? If someone uses a password instead of a sufficiently-random shared secret, will the PRF break?

>We have no way of testing if someone has used a password vs. a shared secret. ...

>... If we say MUST and MUST NOT, we are saying that implementations must somehow test for this. ...

>... SHOULD and SHOULD NOT (with the appropriate wording about the problems of passwords) seems more realistic, but if there truly is a technical problem with using a password in a PRF as Hugo has described, then we should know about it.

full-strength keys, and { MUST | SHOULD } *encourage* the

        "Note that it is a common but [[ typically ]] insecure practice to have a
        shared key derived [[ solely ]] from a user chosen password[[,
        without incorporating another source of randomness ]]."

-- David

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Thu, 10 Apr 2003 10:15:42 -0700

At 11:57 AM -0400 4/10/03, David Jablon wrote:
>I think I took a broader view of what "break something" means.
>In the spirit of Hugo's medical analogy:
>"The operation was a success!  But the patient died from complications."
>I think the use of very weak keys breaks the utility of the method,
>and even if allowed, should not be encouraged.

It doesn't break the utility of the method, it weakens it. There is a 
huge difference there. If it breaks it, you cannot ever allow it; if 
it weakens it, you are responsible for pointing out the weakness.

>But you're absolutely right that I haven't justified the "MUST NOT" text,
>given that I choose not to debate accomodation for weak keys.
>"MUST NOT" doesn't work in that sense, regardless of what "I prefer".
>
>I wonder if we can agree that the "MUST" text in the first part works?
>Especially in light of the two other points that Hugo raised:
>(1) that having the first case be "MUST" fixes other problems, and
>(2) that it still permits implementors to derive full-length keys from
>passwords of arbitrary length using arbitrary functions, if they so choose.

No, we still don't agree. If we say that the definition of MUST etc. 
comes from RFC 2119, we have to use that definition. This isn't 
hair-splitting: it is simple protocol mechanics.

The "other problems" that it fixes are non-fatal problems. They are 
related to the weakness of passwords, namely their susceptibility to 
faster dictionary attacks, but they are not fatal to the protocol. 
They don't affect the communication channel.

Please remember that we are talking about pre-shared keys here: 
*both* parties have to agree to using any particular key. If that is 
their shared security policy (even after our exhortations about the 
weakness of it), then that is what they want.

>  >But that is quite different than mandating that IKEv2 systems have 
>to check the randomness of the preshared key.
>
>Fine. I didn't propose that, and I never meant such a mandate to be implied.

By using a MUST in the proposed wording, you are saying that the 
implementation *has* to prevent passwords from being used.

>  >That is not what RFC 2119 says for the difference between SHOULD 
>and MUST. If you want us to redefine the words in RFC 2119, we can, 
>but you can't both normatively reference RFC 2119 and use the 
>argument above.
>
>It's not a definition issue.  In the first part, "MUST" is 
>justified, but in the
>second part, "MUST NOT" isn't.
>
>Part 1:
>>>         ... this key {SHOULD | MUST} be of the length
>>>         of the key for the prf agreed for use by the parties, ...
>
>I see no need to re-define "MUST" and "SHOULD" to support this point:
>The "SHOULD" here gives license to an implementator to do potentially
>nasty things, like say, truncating all such keys to 64-bits,
>in the interest of handling passwords in some way.

Only if they have a technical reason to do so; that's what RFC 2119 says.

There is no technical reason that I know of that says that the length 
of the key matters to the PRF. If the length is shorter, the PRF will 
not fail, it will simply produce that much less value.

>That "MUST" here helps to guarantee interoperability when using
>full-length keys, and that "SHOULD" does not, is something I thought
>you'd agree with.  And if not then, then perhaps now, in light of points
>(1) and (2) above.

Sorry, maybe I'm being dense. I don't see how the SHOULD would not 
guarantee the interoperability. Let's say that both sides are using a 
PRF that wants 128 bits of keying material, and the two parties agree 
to a shared secret of "Baseball2003". How is the guarantee of 
interoperability broken?

>I see the point, but I'm not so sure about where that scope line is, 
>or should be.

The IETF almost never mandates how a user interface or documentation 
should act. This is meant to be an IETF protocol, so we have to 
follow the IETF rules. That's why we are using RFC 2119, even though 
we could use some other definitions of MUST and SHOULD if we wanted 
to.

>I think the current draft has already crossed the line in talking 
>about the kinds
>of keying material (e.g. passwords) that users will presumably stuff into the
>user interface.

Where in the draft is that?

>   And to maximize interoperability, one may wish to consider
>the type and form of keying material that can be input (or output?), and any
>relevant transformations that may be used by different implementations.

That is already done: none are prohibited.

>Are special password-to-key transformations deemed out of scope?

Of course not: the two sides agree to a shared secret, regardless of 
how the secret is formed.

--Paul Hoffman, Director
--VPN Consortium

---

From: David Jablon <[email-masked]>
Date: Thu, 10 Apr 2003 11:57:27 -0400

Paul,

An amended version of the text in question is at the end.

The rest of this note is meant to explain or clarify any remaining
differences of opinion, or mistakes.

At 04:17 PM 4/9/03 -0700, Paul Hoffman / VPNC wrote:
>It sounds like you do. ...

No, I really, really don't want to debate the *allow for* point.
(regardless of how I feel about that practice. :-)

>... RFC 2119 has very specific definitions for SHOULD, SHOULD NOT, MUST, and MUST NOT. Saying "MUST NOT" has very different semantics than "SHOULD NOT do this because it is weak".
>I assume you are not proposing that we remove the normative reference to RFC 2119. If you are, that's a very different topic...

I pointed out a problem or two with using "SHOULD", that don't
exist when using "MUST".  You noted different problems or issues
with using the "MUST", "MUST NOT", and "SHOULD NOT" text.

Surely, we can both assume we're at least *trying* to properly use
these terms, despite any momentary blindness we might have
for the other's viewpoint.

>I don't either, that's why I asked. "MUST NOT" would indicate that it would break something, "SHOULD NOT" would indicate that the the something would work but probably not the way one would want.

>I have never read a security proof, but if they rely on user-selected things like preshared keys to have a particularly amount of randomness, then they are not based on reality. No matter what you tell them, users will sometimes choose passwords or even non-password preshared secrets with less than 112/128 bits of randomness. They just will.
>
>We are designing IKEv2 for Internet users, not for people who write security proofs. ...

You're preaching to a choir-boy.

User security and user convenience are surely good things to seek.
And I'd prefer to see implementors and users, that choose to use
passwords, encouraged to seek alternate methods, where one may
have a better chance of achieving these goals simultaneaously.
I think that is part of the value of EAP.

>... Having said that, I obviously support telling users as well as we can what they should do to make their systems secure in the way that the security proof says it is. ...

Good. I too like "telling users what they should do to make their systems secure."
And I see no need to qualify that point.

>But that is quite different than mandating that IKEv2 systems have to check the randomness of the preshared key.

>We should obviously fix that.

Good.

>That is not what RFC 2119 says for the difference between SHOULD and MUST. If you want us to redefine the words in RFC 2119, we can, but you can't both normatively reference RFC 2119 and use the argument above.

It's not a definition issue.  In the first part, "MUST" is justified, but in the
second part, "MUST NOT" isn't.

However, mandating a fixed key length does imply something about
transformations that may be used to derive a key from a variable-length
password.  But, in light of your comments below, it's not clear to me
whether such transformations are in the proper scope of this document.

Part 2:
>>       ... this key

I concede the point that the "MUST NOT" version doesn't accomodate
implementations that allow weak keys to be derived from passwords.
To accomodate this practice, this could be either "SHOULD NOT"
or "should not".  (More on that below.)  I think either form permits,
but doesn't promote the practice, which seems reasonable.

>By using "MUST", you are.

No, but I could see why you might think so. I tried to acknowledged the
legitimacy of your alternate interpretation by proposing an alternate
solution:

>>...
>Ah, much better! There is an interoperability reason why they MUST: some systems designed for people who can't enter passwords if they tried will have preshared secrets that are long.

Good.  (I think.)

>Now you are talking about the user interface, which most definitely is out of scope for this protocol document. If you want to write an implementation guide for IKEv2, this would obviously be appropriate there.

I see the point, but I'm not so sure about where that scope line is, or should be.

I think the current draft has already crossed the line in talking about the kinds
of keying material (e.g. passwords) that users will presumably stuff into the
user interface.  And to maximize interoperability, one may wish to consider
the type and form of keying material that can be input (or output?), and any
relevant transformations that may be used by different implementations.
Are special password-to-key transformations deemed out of scope?
If so, how is a requirement to be able to permit input of any full-strength
key, which seems similarly a user interface issue, justified as being in scope?

In any case, I hope we agree that its generally a good thing to
recommend discouraging use of shared secret keys that are derived solely
from passwords without another source of randomness, and that it's good
to elaborate the security implications of not following that recommendation.

>I would leave out the "typically": you simply don't see passwords with 112 or 128 bits of randomness. I don't agree with the final clause because we can't mandate that IKEv2 systems change the password on the user. Instead, you could say "In order to get preshared secrets with a sufficient amount of randomness, users typically need those preshared secrets supplied by systems that compute them."

Ok.  I sometimes use the term "password" broadly to encompass other kinds
of memorizable authenticators, but expanding discussion to include
high-entropy passphrases seems like opening an even larger can.

In light of the above, and in the spirit of being constructive,
see if the following text addresses your concerns:

        "When pre-sharing a key for use in prf-based authentication
        (i.e., "Shared Secret") the key MUST be of the length
        of the key for the prf agreed for use by the parties.
        The implementation must permit the use of any specific key
        value of that length, and the key should not be derived solely
        from a password or other data that is shorter than or is less
        random than a truly random key of the appropriate length. ..."

Even though "is shorter than" seems redundant in light of
"is less random than", I think this makes it clear that password
length and key length are separate matters.

-- David

---

From: David Jablon <[email-masked]>
Date: Sat, 12 Apr 2003 11:01:05 -0400

Paul,

In light of your repeated inappropriate referrals to RFC 2119,
a few things need to be said.

At 10:15 AM 4/10/03 -0700, Paul Hoffman / VPNC wrote:
>It doesn't break the utility of the method, it weakens it. There is a huge difference there. If it breaks it, you cannot ever allow it; if it weakens it, you are responsible for pointing out the weakness.

There is no huge difference between a 20-bit key and a zero-bit key, in this method.
They're both broken. Do you really want to argue otherwise?

Paul wrote:
>No, we still don't agree. If we say that the definition of MUST etc. comes from RFC 2119, we have to use that definition. This isn't hair-splitting: it is simple protocol mechanics.

I see you also don't agree with being particularly polite too, in continuing
to imply that I am somehow ignorant of the rules or unable to apply them.

Regarding the text in question:

It merely mandates the size of a value that used to create another protocol
element, in the interest of guaranteeing interoperability and increasing
security.  This is more than sufficient motivation for using the term MUST.

Whether the text actually achieves those objectives, without introducing
unwanted side-effects, may be a point of debate. But it cannot legitimately
be dismissed by simply telling the opponent to go read a dictionary.

Speaking of which:

 From RFC 2119:
>6. Guidance in the use of these Imperatives
>
>  [The imperative "MUST"] MUST only be used where it is
>   actually required for interoperation or to limit behavior which has
>   potential for causing harm (e.g., limiting retransmisssions)

Regarding interoperation, it is actually required that two parties
agree on key size.  This motivates providing clear guidance for
the appropriate key size, or range of key sizes, that implementations
must support.  And I have heard no technical reason of any kind to
motivate using a *key* size other than the size of the prf key.

Note, again, that password size is a different matter than key size.
Specifying limits for acceptable key length does not imply any limits
on the length of a password. One can use hash, padding, and
truncation functions to transform any password into a key of any
desired length. Limitations on key size may constrain the choices
of such a transformation method, but, I believe this could only
have a *positive* effect on interoperability, even if you dismiss
Hugo's stated positive effect on security.

Regarding security, I simply call attention to the words "to limit
behavior which has the potential for causing harm".  Maybe I've
misinterpreted your words, but this sounds like a *significantly*
lower threshhold for use of the term "MUST" than your interpretation.
Are "retransmissions" so much more devastating than using a
very weak key?

Paul wrote:
>Please remember that we are talking about pre-shared keys here: *both* parties have to agree to using any particular key. If that is their shared security policy (even after our exhortations about the weakness of it), then that is what they want.

I presume your words attempt to justify the point that people
should be able to get the rope to do it.  Fine.  I gave that one to you
already, and I won't debate it ... unless you really really want me to.

My point is that people already have that rope, to use a password of
any size or quality, regardless of any MUST/SHOULD limitations on
key size.  Thus, your words are pointless in an argument against
the use of "MUST" in this context.

>Only if they have a technical reason to do so; that's what RFC 2119 says.

Loose specs. sink ships.  Can anyone think of *any* legitimate technical
reason to use other *key* sizes?  Why leave potential implementors
guessing?

>There is no technical reason that I know of that says that the length of the key matters to the PRF. If the length is shorter, the PRF will not fail, it will simply produce that much less value.

I believe that a decreased level of security, with the *potential* to
cause harm, perhaps by naive or confused implementors, *is* a valid
technical reason. Especially if the concern is easily avoided.

Paul wrote:
>Sorry, maybe I'm being dense. I don't see how the SHOULD would not guarantee the interoperability. Let's say that both sides are using a PRF that wants 128 bits of keying material, and the two parties agree to a shared secret of "Baseball2003". How is the guarantee of interoperability broken?

I'm going to deliberately sound dense in this first part of the answer, to make a point:

I have no idea what it means to "agree on a shared secret [key] of "Baseball2003"".

Of course, I do have a fairly good idea of what it means to agree on a shared secret
*password* of "Baseball2003".  But without knowing binary character representation
(ASCII, UNICODE, ...?) and other aspects of the necessary, but unspecified, password-to-key
transformation function (hash it, pad it, truncate it, include the null, ...?), it's not at all clear
that two different implementations will interoperate using a shared password.

Second, the SHOULD version of the text by itself does not absolutely guarantee
support for *keys* that have a size that matches the prf.  One implementation may
use fixed 128-bit keys, another may use 256, and a third may use another arbitrary
range, all for reasons that a (perhaps naive) implementor may deem technically valid.
How can one determine a set of keys that will work for all implementations?
"SHOULD support X" is not the same as "MUST support X and MAY support Y".

There are multiple kinds of interoperability concerns, between different
implementations using a given key, between different implementations
using a given password, and between different implementations where
only one provides a convenient means to enter a password.

But even if the text is *never* be clear about how to deal with passwords in a
standard way in this pre-shared key mechanism, it *must* be crystal clear
how to deal with keys.  The MUST version achieves that, and draws a clear
line in the sand between passwords and keys, whereas the SHOULD version
does neither.

Paul wrote:
>The IETF almost never mandates how a user interface or documentation should act. This is meant to be an IETF protocol, so we have to follow the IETF rules. That's why we are using RFC 2119, even though we could use some other definitions of MUST and SHOULD if we wanted to.

Please, spare us all the unnecessary lecture.

>Where in the draft is that?

Surely you're not asking about where in the draft it talks about passwords,
and a password obviously has to come from somewhere. But this is old news.
I addressed your concern anyway.   Just in case you missed it, I carefully
avoided using RFC 2119 terms with regard to passwords in the text in
the message to which you've responded, in light of your concern that
passwords are elements of the user interface.

My main point, in case I haven't beaten it to death by now, is that a "password"
is not the same thing as a "key".  Part of your argument only makes sense
if one mistakenly interprets these terms as synonyms.

Regardless of how the text ends up, I urge that the distinction between
passwords and keys be kept clear, and that at least interoperability when
using keys be guaranteed.

-- David