[NSIS] [Fwd: secdir review of draft-ietf-nsis-nslp-natfw-13.txt]

[Magnus Westerlund <[e-mail]>]

Hi NSIS

Many thanks to Catherine Meadows (CC) who has done the Security 
Directorate review attached. It was done on my and the WG chairs request 
through the security ADs to help check the security details of the 
document. It contains the normal boilerplate for document that are in 
IESG review, but as you know this document isn't in that step yet. I 
hope this can help improve the document.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------

--- Begin Message ---

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This ID describes a protocol by which hosts may signal along the path  
used
for transport of data packets the information necessary to configure
NATs and firewalls
according to the needs of the
application data flows.  Not surprisingly, the use of this protocol  
by unauthorized
hosts could cause major security problems.  The security  
considerations considerations section of this document describes the  
problems in detail,
and outlines recommendations for solutions.  These are to have
security mechanisms providing data origin authentication, replay  
protection, integrity protection, and optional confidentiality  
protection.  According to this document, uch security
mechanisms can be provided for neighboring nodes
by using a mutually authenticated
transport layer secured connection and by relying on authorization by  
the
neighboring NATFW NSLP entities, as well as randomly generated (that is,
unpredictable) session IDs.

For non-neighboring nodes (presumably, this means nodes that do not  
share
a security association) some sort of authorization is still  
necessary.  The document
discusses the possibility of using authorization tokens for this, and  
also provides
some recommendations for protecting them (e.g. protection against  
tampering
and confidentiality to protect against replay).  The document does not
go into detail about this, apparently because the usage of  
authorization tokens
in NPLS is covered in another document (referenced in this ID).

This security strategy looks plausible, but I found the justification  
for it very hard to follow.  It starts with a number of possible  
attacks that an unauthorized host could perform using NSLP.  Almost  
all of these attacks can be prevented by providing authorization (the  
exceptions are one or two denial of service attacks), and  
recommendations for authorizations are accordingly provided.    
However, there
are two cases in which such recommendations are lacking.  In one of  
these
(5.2.3, data sender behind a firewall), no reason is given for the  
lack of a recommendation.  In the other (5.8, misuse of unreleased  
sessions), it is claimed
that this will be addressed by the NATFW NSLP.  This last confused me;
isn't that the protocol that this document describes?

The list of attacks appears to have grown up over a period of time as  
the document went through its various iterations.  In its current  
form, the list is not very helpful, especially as the end of the  
security considerations section, in which the actual recommendations  
are made do not reference them explicitly.  Instead, there
are somewhat vague comments such as
    Almost all security threats at the
    NATFW NSLP layer can be prevented by using a mutually authenticated
    Transport Layer secured connection and by relying on  
authorization by
    the neighboring NATFW NSLP entities.
It would have been helpful for the reader to know what is meant by  
"almost all"
without having to go back through the entire list of attacks.

I would suggest that the authors provide a tightened up, condensed  
account of the
security threats against NSLP.  There is no need to try to have an  
exhaustive list
of attacks; indeed such a list will be of limited use since one can  
never be certain that all the possibilities can be exhaustive.   
Instead, it would be more helpful to described classes of threats,  
with some illustrative examples.

In the final section, where the recommendations for security  
mechanisms are
made, you need to be explicit about the types of threats that are  
addressed.
In particular,  some characterization of the types of threats that  
are and are not addressed by authentication and authorization of  
neighboring nodes needs to be provided,


I am wondering if it would not be a good idea to have a separate ID
describing the security mechanisms that need to be used by this  
protocol.
The WG already seems to be halfway there, since they are already working
on an ID for authentication tokens.

Catherine Meadows
Head, Formal Methods Section
Center for High Assurance Computer Systems
Code 5540
Naval Research Laboratory
Washington, DC 20375
phone: [phone]
fax: [phone]

--- End Message ---

_______________________________________________
nsis mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/nsis