rfc3114.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 788 行 · 第 1/2 页


RFC 3114       Implementing Company Classification Policy       May 2002


   The Amoco policy does not identify any privacy marks but the
   classification labels defined for availability and integrity would be
   most appropriately displayed here.  The CRITICAL, MAXIMUM, MEDIUM,
   and MINIMUM labels are examples of information classifications that
   are not used for access control.

   In general, the privacy marks should provide brief but clear
   direction to the user on how to handle the information.

2.2.1.4 Security Categories

   Security categories or caveats are not specified in any of the sample
   policies.  However, they are used in at least 2 of the companies.
   Though the security categories are not defined formally in their
   security policies, once locally defined they are formal and are to be
   enforced.  The security categories are defined when necessary to
   provide identifiable proprietary information more granular access
   control.  A category can be based organizationally or by project
   (i.e., Legal Only or Project Vallor).

2.2.1.4.1 Syntax

   Security categories are represented in the RFC 2634 ESSSecurityLabel
   (to specify the sensitivity of labeled data) and X.501 Clearance
   attribute (to specify an entity's authorizations) using the following
   syntax.

   SecurityCategories ::= SET SIZE (1..ub-security-categories)
                          OF SecurityCategory

   ub-security-categories INTEGER ::= 64

   SecurityCategory ::= SEQUENCE {
     type  [0] OBJECT IDENTIFIER
     value [1] ANY DEFINED BY type } -- defined by type

   One example of a SecurityCategory syntax is SecurityCategoryValues,
   as follows.

   When id-securityCategoryValues is present in the SecurityCategory
   type field, then the SecurityCategory value field could take the form
   of:

   SecurityCategoryValues ::= SEQUENCE OF UTF8String







Nicolls                      Informational                      [Page 8]

RFC 3114       Implementing Company Classification Policy       May 2002


2.2.1.4.2 Use

   An organization will define a securityCategoryType OID representing
   the syntax for representing a security category value within their
   security policy.

   For the example security category syntax, a UTF8String is used to
   convey the security category value that applies to the labeled
   message.  Access MUST be restricted to only those entities who are
   authorized to access every SecurityCategoryValue.  Access is
   authorized if the ESSSecurityLabel SecurityCategoryValue EXACTLY
   matches the Clearance SecurityCategoryValue.

2.2.2 Attribute Owner Clearance

   The security clearance and category authorizations for the user are
   defined in the clearance attribute.

2.2.2.1 Amoco User

   Clearance:
     policyId:  1 2 840 113549 1 9 16 7 1
     classList:  amoco-general              (6),
                 amoco-confidential         (7),
                 amoco-highly-confidential  (8)

2.2.2.2 Caterpillar User

   Clearance:
     policyId:  1 2 840 113549 1 9 16 7 2
     classList:  caterpillar-public              (6),
                 caterpillar-confidential-green  (7),
                 caterpillar-confidential-yellow (8),
                 caterpillar-confidential-red    (9)

2.2.2.3 Whirlpool User

   Clearance:
     policyId:  1 2 840 113549 1 9 16 7 3
     classList:  whirlpool-public        (6),
                 whirlpool-internal      (7),
                 whirlpool-confidential  (8)









Nicolls                      Informational                      [Page 9]

RFC 3114       Implementing Company Classification Policy       May 2002


2.2.3 Security Category Example

   This section includes an example RFC 2634 ESSSecurityLabel including
   the example Security Category syntax.  This section also includes
   example X.501 Clearance attributes.  One of the example Clearance
   attributes includes a set of authorizations that pass the access
   control check for the example ESSSecurityLabel.  The other example
   Clearance attributes each include a set of authorizations that fail
   the access control check for the example ESSSecurityLabel.

   These examples use the id-tsp-TEST-Whirlpool OID defined in section
   2.2.1.1.  Assume that the security policy identified by id-tsp-TEST-
   Whirlpool defines one securityCategoryType OIDs as follows:

   id-tsp-TEST-Whirlpool-Categories OBJECT IDENTIFIER ::= { id-tsp 4 }

   Example ESSSecurityLabel:
    security-policy-identifier: id-tsp-3
    security-classification: 8
    privacy-mark: ATTORNEY-CLIENT PRIVILEGED INFORMATION
    security-categories: SEQUENCE OF SecurityCategory

   SecurityCategory #1
     type:  id-tsp-4
     value:  LAW DEPARTMENT USE ONLY

   Example Clearance Attribute #1 (passes access control check):

   Clearance:
     policyId: id-tsp-3
     classList BIT STRING: Bits 6, 7, 8 are set to TRUE
     securityCategories: SEQUENCE OF SecurityCategory

   SecurityCategory #1
     type:  id-tsp-4
     value:  LAW DEPARTMENT USE ONLY

   Example Clearance Attribute #2 (fails access control check because
   SecurityCategoryValues do not match):

   Clearance:
     policyId: id-tsp-3
     classList BIT STRING: Bits 6, 7, 8 are set to TRUE
     securityCategories: SEQUENCE OF SecurityCategory







Nicolls                      Informational                     [Page 10]

RFC 3114       Implementing Company Classification Policy       May 2002


   SecurityCategory #1:
     type:  id-tsp-4
     value:  HUMAN RESOURCES USE ONLY

2.2.4 Additional ESSSecurityLabel Processing Guidance

   An implementation issue can be the mapping of the security label
   values to displayable characters.  This is an issue for users who
   want to develop and retire their own classifications and categories
   on a regular basis and when the values are encoded in non-human
   readable form.  Applications should provide a means for the
   enterprise to manage these changes.  The practice of hard coding the
   mapping into the applications is discouraged.

   This issue is viewed as local issue for the application vendor, as
   the solution does not need to be interoperable between vendors.

   An approach is the use of a Security Policy Information File (SPIF)
   [ISO15816].  A SPIF is a construct that conveys domain-specific
   security policy information.  It is a signed object to protect it
   from unauthorized changes and to authenticate the source of the
   policy information.  It contains critical display information such as
   the text string for security classifications and security categories
   to be displayed to the user, as well as additional security policy
   information.

   Another implementation issue can be obtaining the recipient's
   certificate when sending a signed-only message with a security label.
   Normally the recipient's certificate is only needed when sending an
   encrypted message.  Applications will need to be able to retrieve the
   recipient's certificate so that the recipient's clearance information
   is available for the access control check.

3. Security Considerations

   All security considerations from RFC 2630 [CMS] and RFC 2634 [ESS]
   apply to applications that use procedures described in this document.














Nicolls                      Informational                     [Page 11]

RFC 3114       Implementing Company Classification Policy       May 2002


References

   [AC509]      Farrell, S. and R. Housley, "An Internet Attribute
                Certificate Profile for Authorization", RFC 3281, April
                2002.

   [CERTCRL]    Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
                X.509 Public Key Infrastructure Certificate and
                Certificate Revocation List (CRL) Profile", RFC 3280,
                April 2002.

   [CMS]        Housley, R., "Cryptographic Message Syntax", RFC 2630,
                June 1999.

   [ESS]        Hoffman, P., Editor, "Enhanced Security Services for
                S/MIME", RFC 2634, June 1999.

   [MUSTSHOULD] Bradner, S., "Key Words for Use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

   [X.501]     "ITU-T Recommendation X.501: Information Technology -
                Open Systems Interconnection - The Directory: Models",
                1993.

   [X.509]     "ITU-T Recommendation X.509 (1997 E): Information
                Technology - Open Systems Interconnection - The
                Directory: Authentication Framework", June 1997.

   [ISO15816]  "Information Technology - Security Techniques - Security
                Information Objects for Access Control", ISO/IEC FDIS
                15816:2000.

Acknowledgements

   I would like to thank Russ Housley for helping me through the process
   of developing this document, John Pawling for his technical
   assistance and guidance, and Dan Quealy for his security policy
   expertise.  I would like to thank Ernst & Young LLP and Telenisus for
   supporting the development of this document while I was employed
   there. I would also like to thank the good people at Amoco (bp),
   Caterpillar and Whirlpool who allowed me to use their policies as the
   real examples that make this document possible.

   Caterpillar and Whirlpool were each asked if they would like to
   provide contacts in regards to their security policies, but declined
   the offer.





Nicolls                      Informational                     [Page 12]

RFC 3114       Implementing Company Classification Policy       May 2002


Author's Address

   Weston Nicolls
   Forsythe Solutions
   7500 Frontage Rd
   Skokie, IL 60077

   Phone: [phone]
   EMail: [e-mail]










































Nicolls                      Informational                     [Page 13]

RFC 3114       Implementing Company Classification Policy       May 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Nicolls                      Informational                     [Page 14]