PD 0115: Third Party Authentication is permitted by the ALFWPP-MR
- Subject: PD 0115: Third Party Authentication is permitted by the ALFWPP-MR
- From: "Observation Decisions Review Board" <firstname.lastname@example.org>
- Date: Tue, 21 Dec 2004 08:02:07 -0800
- Content-description: Mail message body
- Content-transfer-encoding: 7BIT
- Content-type: text/plain; charset=US-ASCII
- Priority: normal
During its October 2004 meeting, while exploring an on-going discussion of
authentication, the ODRB discovered something that fell through the cracks in
CCEVS-OD-0188. Specifically, the OD indicates that "The PP will be changed to
move authentication into the environment and to update the Objectives,
Threats, and Policies statements", yet this was never done. The following PD
was developed to capture this. In particular, this PD attempts to relax the
rigid position of the Application-Level Firewall PP to allow third party
authentication servers to be employed with a TOE.
Third Party Authentication is permitted by the ALFWPP-MR
There is an error in the ALFWPP-MR, dated June 2000, in that the PP does not
permit authentication to be performed by any device/component other than the
Currently, the TOE objective, O.IDAUTH, in the PP states, "The TOE must
uniquely identify and authenticate the claimed identity of all users before
granting a user access to TOE functions or, for certain specified services, to
a connected network." By being an objective for the TOE, this objective does
not provide to developers the flexibility to use other authentication
components, such as RAS, TACACS+, RADIUS, to assist in authenticating users and
services, as is typically done in today's firewall environments.
This PD effects a change that will relocate the identification and
authentication objectives in the PP to the environment.
Developers and evaluators should proceed as if the TOE objective, O.IDAUTH, has
been moved and made a security objective for the IT environment (with
appropriate renaming to reflect the conventions for IT Environment objectives).
Its accompanying/mapped SFRs, FIA_UID.2 and FIA_UAU.5, should also be
considered as security requirements for the IT environment.
Additionally, the U.S. Government Firewall Protection Profile for Medium
Robustness Environments, dated October 28, 2003, has replaced the ALFWPP-MR.
Many, if not all, of the I&A issues have been remedied in the replacement PP.
Lastly, although ALFWPP-MR is still active and is available/approved for use,
it will be retired on 30 April 2005.
This makes the flawed PP consistent with its successor.
Date Index |
Thread Index |
Problems or questions? Contact email@example.com