Subject: framework v11 to address authorization issues

From: "Yang, Lily L" <[email-masked]>
Date: Tue, 9 Dec 2003 09:11:03 -0800

Hi, all --

The framework team has revised the framework draft (v11) to address comments from Russ Housley as detailed below. We believe all comments from IESG has been addressed with this revision and we are ready to move the document into the final stage of RFC process.

Lily
 <<draft-ietf-forces-framework-11.txt>> 
------------------- Details --------------------------------

Russ's comments:
> 1.  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.
> 2.  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.
> 3. Section 8.1.2 needs to include authorization too.

Summary of changes in v11. The complete document is also attached. 

1) 4.2.2: Association Establishment

[old] The exact details of the security handshake depend on the security solution chosen by ForCES protocol.  

[new] 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.  

2) 4.3: Association Re-establishment

[old] 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] 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.

3) 4.2.5: Proxy FE

[new] 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. 

4) 8.1.2: Impersonation Attack 

[old] Requirement:  The CE or FE must authenticate the message before accepting and processing it.  

[new] 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.