CAP "password" element is inappropriate and a security weakness

emergency-comment message

CAP, which is a "format" not a protocol, provides for an optional, clear-text password element. Given that CAP is a format while a password is data which is appropriate only at link-level or session-level in protocol stacks, the provision of a password in CAP appears to indicate serious confusion of the commonly accepted practice of layering in distributed systems.

Additionally, because CAP messages are intended to be redistributed, it is likely that passwords embedded within CAP messages will be redistributed with those passwords in place. (CAP says nothing of a requirement to remove passwords on redistribution. Also, since CAP provides for an SHA-1 digest of message contents, the password cannot be removed by a redistributor without invalidating the digest.) This introduces a significant security weakness in CAP systems.

As defined, the password in a CAP message can be easily extracted and inserted into maliciously or falsely generated CAP messages without detection. Thus, the password provides no useful ability to disambiguate the origin of messages. While the CAP specification says that passwords should only be used in "secure channels," it appears that the use of a CAP password cannot, in any useful way, accomplish the stated goal of "authenticating the sender" of a CAP message.

Additionally, since the CAP password is cleartext, passwords in CAP messages may be used by attackers to determine the "style" of password which is used by an originator. (For instance, if a password like "1foobar2" is found, an attacker can learn that the originator uses alphanumeric passwords which contain pronounceable components. Similarly, if a password like "07897:LKJ#22cbe8" is seen, the attacker can extrapolate that the originator uses randomly generated passwords.) Given such knowledge, a strategy for attacks on the originator's systems can be finely tuned and be more perfect than would otherwise be the case.

Passwords, if used, should be limited to the link or session layers of distributed protocols. They should not be inserted into message content that is likely to be redistributed. Since CAP V1.0 defines a format, not a protocol, the password element should *not* be supported.