Re: [secdir] sec-dir review of draft-ietf-roll-building-routing-reqs-07

[Derek Atkins <[e-mail]>]

Hi,

First, I do think you need to change the structure and re-introduce the
"Security Considerations" section.

Second, I think it's important (even in a requirements document) to
explain the ramifications of different security tradeoffs.

I agree that you don't need to specify "Use AES-256 in GCM mode" in this
document.  However I do think you need to go into more detail about the
various security services that your protocols will need to define, and
the trade-offs that might happen if they choose to define it one way
versus another.  In other words, what are the security requirements for
your sub-protocols?

I don't think the current draft goes into quite enough detail in
answering these questions.  I think the questions I posed below still
apply, even in a requirements document.  Providing guidance to protocol
designers is still appropriate.

-derek

[e-mail] writes:

> Hi Derek,
>
> As the author of the document, I am trying to describe in this requirements ID
> the flexibility of setting up the security policies (as Adrian notes) rather
> then the application specifics of picking a security policy for a given
> application.  Earlier versions of this ID included this information, but was
> dropped since it was out of scope for the routing protocol.  
>
> I have recently been requested to draft an ID for the 6LowAPP that would deal
> specifically with Building Applications at the application layer rather than
> at the routing layer.  Here, I intend to reinject into this new ID specificity
> as to when different security strategies are required.  I have attached a
> spreadsheet that describes 5 different security policies (rows) that must be
> configurable for many different types of commercial buildings with the varying
> requirements for each building type (columns).  I intend to redraft this
> spreadsheet into a section of the ID.  
>
> I hope this is more of what you're looking for and can accept that I will put
> is into a separate ID.  If you think any of this should be put into the
> existing requirements ID, let me know and I will add it in.
>
> Best Regards,
>
> Jerry Martocci
>
> Adrian Farrel                       To Derek Atkins <[e-mail]>,         
> <[e-mail]>             [e-mail], [e-mail]          
>                                     cc [e-mail],            
> 09/20/2009 05:00 AM                    [e-mail], 
> ┌────────────────────────────┐         [e-mail],              
> │     Please respond to      │         [e-mail],                      
> │       Adrian Farrel        │         [e-mail]              
> │ <[e-mail]> │ Subject Re: sec-dir review of                   
> └────────────────────────────┘         draft-ietf-roll-building-routing-reqs-07
>
> Hi Derek,
>
> I very much appreciate your review.
>
> It is important to understand that this document specifies requirements that
> must/should/etc be satisfied by a protocol designed by the working group.
> Thus, there is no question of what should be deployed or what should be
> implemented.
>
> That is, the document specifies what must be in the protocol spec. We can
> expect the protocol spec to discuss what must be implemented. And either the
> protocol spec or an applicability statement would describe what must be
> deployed.
>
> So, the concerns you raise would be very important in the final protocol
> spec (and I hope the chairs and authors are paying attention), but do not
> seem to me to fit in this document.
>
> Thanks,
> Adrian
>
>>> The Security Considerations appear to take into account various
>>> requirements for different systems.  What seems to be lacking is
>>> direction about how or when to apply various requirements and what
>>> it means to the deployment.
>>>
>>> For example, what would it mean to a deployment if it has
>>> authentication versus not having authentication?  Also, it's unclear
>>> how these requirements would apply to an implementor.
>>>
>>> Variable security policies is a good idea, but it requires more
>>> guidance because the end user will never understand the ramifications
>>> of choosing one policy over another.
>
>

-- 
       Derek Atkins                 617-623-3745
       [e-mail]             www.ihtfp.com
       Computer and Internet Security Consultant