Subject: RE: Security guidelines discussion in the IESG

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Wed, 26 Apr 2006 20:51:45 +0300

> -----Original Message-----
> From: Steven M. Bellovin [mailto:[email-masked]] 
> Sent: Wednesday, April 26, 2006 4:14 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: Security guidelines discussion in the IESG
> 
> On Wed, 26 Apr 2006 14:30:50 +0300, "Romascanu, Dan \(Dan\)"
> <[email-masked]> wrote:
> 
> >  
> > My instinct is to say that the security area need to issue 
> a document 
> > similar to what RFC 4181is for MIB reviewers. The security 
> folks seem 
> > to believe that this role is played by RFC 3552, and that 
> the security 
> > advisors for specific WGs would do the rest. In reality for raqmon 
> > this did not work, and maybe other similar cases exist.
> >  
> Dan, could you give more detail on what's wrong with 3552?  
> As you say, we thought that 3552 was filling that role.
> 
> 		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
>

There are two problems that we have felt directly in the case I was
involved with:

1. Just from reading 3552 (and other) it's hard at least for a
non-security person to figure out which security feature requirements
match the protocols to use. In the RAQMON case, we ended up figuring out
that we didn't need SASL at all, just "mandatory TLS". The confusion
cost us about 5 months already and counting.  Some kind of a guiding
document, including a mapping table or matrix would be extremely useful.

2.. Timeliness - Some of the security framework components are evolving,
new stuff was showed up since RFC 3552 was published, and the security
advisors and reviewers refer protocol developers to this new stuff in
many cases. There is a need of a documentation that is more flexible
than an RFC in keeping pace with the new security protocols and
extensions.

I hope that the other WG chairs involved that encountered similar
experiences would provide more insights. 

Dan

---

From: <[email-masked]>
Date: Thu, 27 Apr 2006 11:08:49 +0300

> experiences would provide more insights. 

In my experience as a document author: RFC 3552 over-emphasizes
communications security.  While the "Internet threat model" (bad guys
in the network between two-or-more honest parties) in Section 3 is of
course very traditional for cryptographic protocols (like IPsec and
TLS), it's IMHO outright misleading for most IETF protocols.

To give just one example: in RFC 4072 (Diameter EAP Application)
security considerations section, the communication security threats
are dealt with a single paragraph. The rest of the five _pages_ deals
with threats arising from authenticated Diameter peers. And this in
Diameter, where the peers you're communicating with are not really
that hostile (and administrative security measures, agreements, etc.
outside Diameter help even if something in Diameter would go wrong).

RFC 3552 does have some text about non-communications security
(half-page "Systems Security" Section 2.3; and the SMTP example in
Section 6), but somehow I feel these are largely overlooked by most
readers. It's much more easier to just enumerate things like
eavesdropping, MitM, replay, etc. in your document's security
considerations text.

Sometimes these issues are specific to a particular protocol, so it's
not quite clear what, say, an update to RFC 3552 should say. Probably
more advice about attacks from authenticated peers: does your protocol
assume that they "behave well", and if not, how is this handled?  Is
the information required to make this access control decision
realistically available? How do you use the authenticated identities?
(E.g., authenticating me as [email-masked] is not alone sufficient to
determine if I'm the "owner" of MIP home address 192.0.2.1, allowed to
allocate 64kbps QoS for some packet flow, or allowed to post on FooBar
Atom-based blog.) And possibly the "Internet threat model" should go
to an Appendix, or at least it should have clear warnings that "if
you're not designing a cryptographic protocol (and you really should
not), these are not your main threats"...

Best regards,
Pasi