Re: IAB draft on security

I am responding to this in what I hope will be seen as a constructive
spirit.  There seems to be a general feeling that this draft contains good
information, but more is desirable.  I try to suggest some areas that I, as
a non-security-expert, might benefit from additional guidance.

I should add that my comments are made from a perspective of application
protocol design, so I may miss many issues that are relevant to lower layer
protocol design.


>                  Security Mechanisms for the Internet
>
>                        draft-iab-secmech-00.txt

[...]
>3. Introduction
>
[...]
>
>   Finally, security mechanisms are not magic pixie dust that can be
>   sprinkled over completed protocols.  It is rare that security can be
>   bolted on later.  Good designs--that is, secure, clean, and efficient
>   designs--occur when the security mechanisms are crafted along with
>   the protocol.

This idea of "designed-in" security is oft-repeated, and I don't think
anyone seriously disagrees (I don't!).

But when I think about it, I'm not really clear what it means to "design
in", other than to design the security mechanisms at the same time as the
protocol (which is effectively what you say) -- is there more?

For example, in dealing with messaging-related protocols it is easy to say
that some form of object security should be applied to the message content,
and cite RFC 1847, S/MIME, OpenPGP, etc.  To me, this feels like "bolt-on"
security but it's not clear to me what more can and should be done.  Can
more guidance be offered?


>4. Decision Factors
>
>
>4.1. Threat Model

I think that a checklist of possible threats might be helpful for
non-security-experts:  it might give us something around which to structure
a "security considerations" section in a protocol goals document.

Looking through your draft (and adding a few I think of), I can see:
- theft of static information
- theft if information in transit (eavesdropping)
- traffic analysis
- service spoofing
- theft of infrastructure use
- disruption of infrastructure
- corruption of data
- spoofing of identity
- denial of service
- insider vs outsider attacks
- social engineering


>   The value of a target to an attacker may depend on where it is
>   located.  A network monitoring station that is physically on a
>   backbone cable is a major target, since it could easily be turned
>   into an eavesdropping station.  The same machine, if located on a
>   stub net and used for word processing, would be at little risk.

This paragraph suggests a difference between a threat and a vulnerability
that is exploited to realize that threat.  In this case, the network
monitoring protocols may have vulnerabilities that can be explpoited to
cause theft/disruption of infrastructure elements.  Thus, the above list
should probably be two:  threats and vulnerabilities.

Some kind of structured approach to guide a non-expert may be helpful.

I can imagine a matrix of threat, exploited vulnerability,
value-to-attacket, value-to-victim, cross-referenced to the kind of
protocol for which this needs to be considered.   I imagine a kind of
living document that can be updated as the threat/vulnerability/usage
models become better understood.

(I'm not trying to suggest a "cookbook" here --that's too much like
pixie-dust-- but a distillation of security knowledge that can hep
designers determine if they have considered the things that a security
expert would naturally consider.)


>4.2. Granularity of Protection
[...]

I think granularity has two impacts:  the domain from which certain kinds
of attack can be launched, and the range of resources that are vulnerable
to an attack -- would these benefit from being separated more clearly?


>4.3. Implementation Layer
>
>   Security mechanisms can be located at any layer.  In general, putting
>   a mechanism at a lower layer protects a wider variety of higher-layer
>   protocols.  The usual tradeoff is reach; lower-layer protocols
>   terminate sooner.
[...]

This is a very interesing characterization, but I am not sure how it helps
a struggling protocol designer.  I seems to me that we have little choice:
either the mechanisms must already exist, or the scope for additional
mechanism is very constrained.


>5. Standard Security Mechanisms
>
>
>5.1. Plaintext Passowrds
[...]
>   Another weakness arises because of common implementation techniques.
>   It is considered good form [MT79] for the host to store a one-way
>   hash of the users' passwords, rather than their plaintext form.
>   However, that may preclude migrating to stronger authentication
>   mechanisms, such as HMAC-based challenge/response.
........................^^^^ add forward reference?

>   The strongest attack against passwords, other than eavesdropping, is
>   password-guessing.  With a suitable program and dictionary (and these
>   are widely available), 20-30% of passwords can be guessed in most
>   environments.

A thought:  I think it's perceived wisdom that it's better to have a fine
granularity of password protection (one per user, possibly per
user/application).  But doesn't this increase the number of passwords in
use, hence the chances of a successful guessing attack?  I guess however
you cut it, passwords are not great.


[...]
>5.7. DNSSEC
>
>   DNSSEC [RFC2065] digitally signs DNS records.  It is an essential
>   tool for protecting against cache contamination attacks; these in
>   turn can be used to defeat name-based authentication and to redirect
>   traffic to or past an attacker.  The latter makes DNSSEC an essential
>   component of some other security mechanisms, notably IPSEC.

Would it be helpful to clarify the importance of DNSSEC when designing
other protocols?


>5.10. Firewalls and Topology
[...]

As guidance for protocol designers, I think it would help to say that
protocols should not be designed to sneak or piggyback their way through
firewalls.  Rather, a firewall administrator should be able to exercise
clear and uncluttered control over which services are allowed through, and
which are not.



And a final thought:  some people have noted that human factors are a big
factor in the non-deployment and failure of security mechanisms.  Would it
be helpful to add a section that discusses human factors, and the kind of
designs that:
(a) make deployment more likely to be achieved, and
(b) reduce the chance of security being compromised or subverted by the
human users.

Tall order, n'est ce pas?


#g

------------
Graham Klyne
(GK@ACM.ORG)

Received on Tuesday, 27 July 1999 12:18:50 UTC