Re: [saag] Additions to RFC 3631?

[Mouse <[e-mail]>]

> Does anyone have any suggestions for additions or corrections to RFC
> 3631?

Yes.  I, at least, do.

> 2.2.  A Word about Mandatory Mechanisms

>    We have evolved in the IETF the notion of "mandatory to implement"
>    mechanisms.  [...blather about interoperability...]

>    It is important to understand that mandatory mechanisms are mandatory
>    to *implement*.  [...]

>                                              Particularly with security
>    mechanisms, just because a mechanism is mandatory to implement does
>    not imply that it should be the default mechanism or that it may not
>    be disabled by configuration.  If a mandatory to implement algorithm
>    is old and weak, it is better to disable it when a stronger algorithm
>    is available.

If the point of a mandatory-to-implement mechanism is interoperability,
allowing it to be disabled is a bad idea; it has pretty much the same
effect on interoperability as not having it there in the first place:
peers cannot count on its availability when speaking with peers they
have no particular knowledge of.

> 3.1.  One-Time Passwords

>    One-time password schemes, such as that described in [RFC2289], are
>    very much stronger than conventional passwords.  The host need not
>    store a copy of the user's password,

This is true of only some OTP schemes (and those schemes are the weaker
for it; any algorithmic relation between the passwords at all is a
potential point of attack).  Other OTP schemes require the host to
store the user's password to exactly the same extent that reusable
password schemes require the host to store their passwords.

>    nor is it ever transmitted over the network.

Again, this depends on the OTP scheme; indeed, most OTP schemes I am
aware of do indeed transmit the passwords used for authentication.

If this discussion is really supposed to be restricted to RFC2289
designs, the punctuation in the introductory sentence is misleading; as
quoted above, it says it's talking about OTP schemes in general, with
RFC2289-style schemes cited as an illustrative example, not as a
restrictive narrowing of the set of schemes being described.

> 3.3.  IPsec

>    The key management for IPsec can use either certificates or shared
>    secrets.  For all the obvious reasons, certificates are preferred;
>    however, they may present more of a headache for the system manager.

The statement that certificates "are preferred" is either false or
incomplete, because certs are preferred only for certain classes of
uses.  For others, a shared secret is better - different uses,
different tradeoffs.

> 3.4.  TLS

>                                                     It's an unfortunate
>    reality that even server side authentication it not as secure in
>    practice as the cryptography would imply because most implementations
>    allow users to ignore authentication failures [...]

If you want to cite "unfortunate realit[ies]", how about the one that
it really is not all that difficult to get a cert for someone else's
domain?  I recall, for example, hearing about the number of certs for
microsoft.com that had been issued to entities having nothing to do
with Microsoft.

> 3.8.  Security/Multipart

>    Security/Multiparts [RFC1847] are the preferred mechanism for
>    protecting email.

Again, asserting that a particular alternative is preferred is either
false or incomplete.  I, for example, have various reasons for
preferring other tools for securing email in many cases.

>    The Digital Signature Standard [DSS] and RSA [RSA] are both good
>    choices; each has its advantages.  [...]
>        [...].  DSS has much better performance than RSA for generating
>    new private keys,

This runs counter to my experience with them within the context of ssh,
for what little that may be worth.

> 4.1.  Plaintext Passwords

>    Plaintext passwords are the most common security mechanism in use
>    today.  Unfortunately, they are also the weakest.  When not protected
>    by an encryption layer, they are completely unacceptable.

Again, this is either false or incomplete.  There is a system I have
been using since early 1992, and co-adminning since late 1992, that
routinely uses reusable plaintext passwords over unsecured TCP
connections over the open Internet (indeed, I don't think we have any
other authentication mechanism available).  For our purposes, that's
entirely suitable, and I don't think it is for the IETF to tell us
otherwise.

Perhaps 3631 is writing strictly from the perspective of security
mechanisms in new protocols being considered for IETF approval; my
comments on 3.3, 3.8, and 4.1 do not apply then, but in that case I
think the introductory text needs to be a good deal clearer.  It's
titled "Security Mechanisms for the Internet", not "Security Mechanisms
for New IETF Protocols", after all.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[e-mail]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B