Subject: ForCES framework: summary of comments from Russ Housley and authors' respond

From: "Yang, Lily L" <[email-masked]>
Date: Wed, 17 Dec 2003 12:08:19 -0800

As I indicated in my postings before, the framework draft has received
some comments from Russ Housley as part of the IESG review.
Unfortunately it tooks us 3 revisions to get everything covered. Per
requests from the chairs, here is a summary of the comments from Russ
Housley  and our respond and revision in its entirety. Please review the
revised text as summarized below for your reading convenience.
Attached is the most recent revision that is uploaded (v12). The changes
from v11 to v12 are very minor: fix "Ipsec" to "IPsec" in one instance,
added "or a physcially secured room" after "inside a box" to better
cover the notion of physical security.
 
Note that the section # changes due to reordering of the Acknowledge
section (now before Security).
 
Lily
 
---------- Comments from Russ Housley & authors' respond & revision
details ------------
As a matter of taste, I would like to see the usual RFC 2119 text
inside Section 1, which is all about definitions.
    [respond] Done.

In section 4.2.2, the document says that a security protocol will
be used for authentication. Clearly, an authorization decision
needs to be made following successful authentication. Section 4.3
needs to discuss authorization as well.
    [respond] we revised both 4.2.2 and 4.3 to explicitly call out
authorization 
as part of the security handshake. 
    [old para in 4.2.2] The exact details of the security handshake
depend on the security solution chosen by ForCES protocol.  
    [new in 4.2.2] The security handshake should include mutual
authentication and authorization between the CE and FE, but the exact
details depend on the security solution chosen by ForCES protocol.
Authorization can be as simple as checking against the list of
authorized end points provided by the FE or CE manager during the
pre-association phase.  Both authentication and authorization must be
successful before the association can be established.  If either
authentication or authorization fails, the end point must not be allowed
to join the NE.  After the successful security handshake, message
authentication and confidentiality are still necessary for the on-going
information exchange between the CE and FE, unless some form of physical
security exists.  Whenever a packet fails authentication, it must be
dropped and a notification may be sent to alert the sender of the
potential attack.  
    [old para in 4.3] Note that security association and state must be
also re-established to guarantee the same level of security exists
before and after the association re-establishment.
    [new para in 4.3] Note that security association and state must be
also re-established to guarantee the same level of security (including
both authentication and authorization) exists before and after the
association re-establishment.

Section 4.2.2 contains a forward reference to section 9. I suspect
that this should be a reference to section 7.
    [respond] Could not find this one.

In section 4.2.5, there is no discussion of security. Given the
authentication (and needed authorization) discussion in section
4.2.2, it seems that authentication and authorization need to be
discussed in the context of the proxy.
    [respond] This is a good point. We added a new paragraph in Section
4.2.5 to point out the security implication of proxy and its reliance on
physical security. 
    [added in 4.2.5] One needs to be aware of the security implication
introduced by the proxy FE.  Since the physical FE is not capable of
implementing ForCES itself, the security mechanism of ForCES can only
secure the communication channel between the CE and the proxy FE, but
not all the way to the physical FE.  It is recommended that other
security mechanisms (including physical security property) be employed
to ensure the security between the CE and the physical FE. 

Section 7.1.2 needs to include authorization too.
   [respond] Done.  The section is in 8.1.2. 
   [old in 7.1.2] Requirement:  The CE or FE must authenticate the
message before accepting and processing it.  
   [new in 8.1.2] Requirement:  The CE or FE must authenticate the
message as having come from an FE or CE on the list of the authorized
ForCES elements (provided by the CE or FE Manager in the pre-association
phase) before accepting and processing it.  

In section 7.2, the phrase "inside a box" should be expanded to
include a physically secure room.
   [respond] done in v12. The section is in 8.2.
   [old para in 7.2] When ForCES is deployed between CEs and FEs inside
a box, authentication, ...
    [new  para in 8.2] When ForCES is deployed between CEs and FEs
inside a box or a 
physically secured room, authentication, ...

In the 2nd paragraph of section 7.2.3 please change "Ipsec's" to
"IPsec's"
[respond] done in v12, in 8.2.3 now.

Section 7.2 suggests the use of IPsec or TLS for security between
the ForCES components. It seems that there are advantages to using
a layer 2 security protocol. In particular, a protocol like SDE
(IEEE 802.10b) would limit participation to components attached
directly to the LAN segment.
    [respond] L2 may be allowed as a deployment option coupled with "no
security" at ForCES layer for a particular L2 technology. But on the
other hand, ForCES protocol should not rely on any praticular L2
security to satisfy security requirements as L2 solution can vary and
ForCES should stay L2-agnostic. So we added a sentence at the 2nd
paragraph of 8.2 to clarify this, without citing SDE (IEEE 802.10b) as a
particular example. 
  [old in 8.2] Both TLS and IPsec can be used potentially to satisfy all
of the security requirements for ForCES protocol.         
  [new in 8.2] Both TLS and IPsec can be used potentially to satisfy all
of the security requirements for ForCES protocol. In addition, other
approaches may be used as well but are not documented here, including
using L2 security mechanisms for a given L2 interconnect technology, as
long as the requirements can be satisfied.