Guidelines for Writing RFC Text on Security Considerations
RFC 3552

IESG comments:

Patrik:
I think the document do a bit more than talking about security
considerations, and that is help for actual designers of the document
which is to have the security considerations. I think that is a good
idea.

But, when looking at the architectual discussions, I would like to have
some wording on two things which are discussed a lot in applications
area.  I have no idea what to write, but would like to have it written
down, and it has to do with TLS:

  - The document talks about TLS in basically two places, regarding
      authentication and securing of a connection. I would like to have
      some more words about what happens if these are combined. I.e.
      my personal view is that TLD for securing connection is a good
      idea, but at the same time for mutual authentication is hard,
      as "The Global PKI" doesn't exist. Because of that, I have
      suggested wg's in apps area to use TLS for securing connection,
      but then things like SASL for authentication.

      Is that a good or bad suggestion? I.e. I would like text
      about when one do authentication and securing of channel.

  - The current implementations of TLS I have seen do secure
      the channel before one in the protocol have passed the
      information about what one want to connect to. This implies
      that if one do virtual hosting of HTTP or SMTP (for example),
      the server doesn't know really what cert to present to the
      client. This leads to "one port per virtual host" which is
      not so fun, as we really want the cert used in TLS be the
      name of the _virtual_domain_ and not the host. This because
      the name of the host is normally fetched from DNS (SRV/MX)
      or whatever else "unsecure" mechanism, while the virtual
      domain is in the URI.

      I would like to have some wording about this aswell.



But, let me emphasize that these are additional things. I think the
document is good, and will help work in my area.

Scott:
notes:
      good document but ....
            the ID needs an abstract
            the actual filename is draft-iab-sec-cons-00.txt
            MUST used but not defined
            references not split
               
            since one of our biggest proboems is people claiming
            that they do not have to security because thir appliction
            will only be run in a closed environment (much of
            the "discussion" in IP Storage) I think its very
            important to have a section in this document that
            addresses that claim head-on (once someting runs on IP
            there is no way for the host to be SURE that its in
            a confined net etc)

            in general I think the doc could use a bit more
            discussion of architecture in that it seems to be
            mechanism-centric

            also - Jeff said some things about IPSec the other day
            that might be good to fold into this document

Bill:

I looked closely at section 6.2, since the VRRP WG is interested in
advancing the VRRP spec to Draft, and the security considerations are
one of the issues. I'm sorry that this is kind of a stream of
consciousness, but it's been rattling around in my head for months and
I haven't managed to get it out properly yet.

Minor initial comment:
Section 6.2.1.3 contains a transcription error, changing RFC 2338's
reference to RFC 2403 into a reference to RFC 2104. This leads to the
note that there should be a recommended algorithm, but 2338 does
recommend HMAC-MD5-96.

However, based on some discussion on the VRRP WG list and my own
analysis, I think there's a large amount of analysis missing from
2338 -- notably, what happens with authentication failures.
Basically, VRRP authentication failures are likely to cause multiple
VRRP master routers (one in each authentication "domain", which I
define as a set of systems that have the same authentication info).
Having multiple VRRP masters is not a situation that was ever
considered in the spec, and could prove more disruptive than an attack
on the VRRP protocol itself.

The threat: an attacker on the same LAN can send VRRP messages claiming
to have high priority. Since the IP Address Owner never gives up being
the forwarder, the attacker can only disrupt the network when the
IP Address Owner is down; it can then cause itself to be elected
Virtual Router Master and e.g. blackhole or MITM all the traffic.

Relative threat analysis: This is much easier in two ways: ARP and
switch-fooling. ARP's vulnerabilities are well known, and were in
fact accidentally demonstrated at the Yokohama IETF. Fooling an auto-
learning switch into forwarding you traffic destined for mac address M
by sourcing packets with mac address M is trivial, and in fact this
procedure is described in RFC 2338.

Now, just because there are easier ways to accomplish this doesn't
mean that we shouldn't try to secure VRRP, but since
a) authentication failures cause multiple masters to be elected
b) multiple masters are potentially very disruptive
this tradeoff should be analyzed.

Multiple masters can cause disruptions from black holes to duplicated
traffic, depending on the environment. In a switched environment,
they can cause the switches' idea of where the virtual router MAC
address is attached to change twice per second, possibly causing
forwarding irregularities during the switch (and possibly directing
traffic for some of the time to a misconfigured router).

My final analysis: the Simple Text Password turns minor
misconfigurations into major disruptions (it's better to just let the
misconfigured router participate in an unauthenticated VRRP election
than to have it elect itself as master because all the proper election
packets fail authentication), so should be eliminated. The IPSEC AH
section doesn't talk about keying, even though it sends to multicast 
groups; I think it should talk about using static keys and disabling
replay prevention, and optionally using a group keying protocol when
one is defined. The document also needs to talk about these tradeoffs
of multiple masters due to authentication failures.

The body of the document also could use some tightening up wrt
security, e.g.

7.1 Receiving VRRP Packets
     
      Performed the following functions when a VRRP packet is received:
...
            - MUST perform authentication specified by Auth Type

but the check that I'm willing to accept this auth type is not
explicitly present, so a packet with no authentication would pass these
rules even if the router was configured to send plain-text
authentication. This is probably not a draft-iab-sec-cons issue, though.

Ned:
Section 4.2, fourth paragraph. It says in part "For instance, SASL can
be used merely as an authentication framework--in which case the SASL
exchange occurs but the rest of the connection is unprotected, but can
also negotiate TLS as a mechanism.". This is incorrect; there is no
defined way to negotiate TLS as a mechanism in SASL, and as a practical
matter protocol that provide the means to use both SASL and TLS do so
with separate commands or negotiations. What SASL provides is a means
to negotiate either an integrity or confidentiality layer coincident
with authorization, distinct from similar layers provided by TLS.

Some mention of the SASL EXTERNAL mechanism and its ability to import
authentication credential from outside sources like TLS might also be
useful here. It certainly adds yet another nuance to the overlapping
nature of our security building blocks.

Section 6.1. A comparison of this hypothetical security considerations
section for SMTP with the recently constructed one that appears in the
updated SMTP specification RFC 2821 shows a number of interesting
differences. Generally speaking what appears in section 6.1 focuses on
how additional external services can be used to advantage to make SMTP
more secure, whereas what appears in RFC 2821 focuses on security
issues within SMTP itself.

I think section 6.1 puts the focus in the wrong place. While it is
undeniably true that increased use of security building blocks is a
Good Thing, I think it is far more important for security considerations
sections to focus on security issues inherent in the specification
itself. Endless reiteration that IPsec, TLS, S/MIME, PGP are good tools
to use looks more and more like security pixie dust to me.

I would therefore suggest that this section be redone to at least
mention the many security issues inherent in SMTP that are raised in
RFC 2821.

Section 6.1.1. I find it curious that SASL isn't listed as a tool to
use in the SMTP context. In practice SASL is _the_ way that
authentication is done in SMTP; such usage has become quite
commonplace as a means for remote users to get their SMTP server to
accept messages for relay. I think it needs to be on this list and there
needs to be a section describing its use.

Finally, I see no mention in this document of the risks of executable
content. We have a lot of RFCs that define media types; when defining 
a media type the single most important issue that needs to be addressed
in a security considerations section is whether or not the type admits
executable content and if it does what steps are taken to prevent it
from becoming a problem. I think this at least needs to be mentioned here.


Thomas:
Overall, this document is great and needed addition. Thanks for doing
it!

One thing I think would benefit from some explicit discussion,
however, concerns distinguishing between threats caused by on-link
attackers, on-path attackers, and off-path attackers. Two issues here:

1) it may make sense in the security considerations section to talk
      about these classes because the protocol itself may be deployed in
      more limited scope environments, and the threat models are then
      different.

2) In some cases, it makes sense for the protocol itself to add
      mechanisms to reduce threats that aim at thwarting (say) just
      off-link or off-path attackers. Again, this may be useful for
      certain deployments. E.g., VRRP uses the TTL=255 trick to reduce
      threats from off-link attackers. MIPv6 (still an ID) pays a lot
      more attention to threats from off-path attackers than on-path,
      since on-path attackers have such a large arsenal of tricks.
     
I'm not immediately sure the best place to put in text related to the
above. Section 3 or 3.1 perhaps?

Section 3 says:

      By contrast, we assume that the attacker has nearly complete
control of the communications channel over which the end-systems
communicate. This means that the attacker can read any PDU
(Protocol Data Unit) on the network and undetectably remove,
change, or inject forged packets onto the wire. This includes
being able to generate packets that appear to be from a trusted
machine. Thus, even if the end-system with which you wish to
communicate is itself secure, the Internet environment provides
no assurance that packets which claim to be from that system in
fact are.

I think "assume attacker has nearly complete control" is basically
right by default, but that folks should also think about whether it
makes sense to distinguish between on-path, off-path, etc.