File: rfc3114.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (787 lines) | stat: -rw-r--r-- 27,764 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787






Network Working Group                                         W. Nicolls
Request for Comments: 3114                            Forsythe Solutions
Category: Informational                                         May 2002


              Implementing Company Classification Policy
                     with the S/MIME Security Label

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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

Abstract

   This document discusses how company security policy for data
   classification can be mapped to the S/MIME security label.  Actual
   policies from three companies provide worked examples.

1. Introduction

   Security labels are an optional security service for S/MIME.  A
   security label is a set of security information regarding the
   sensitivity of the content that is protected by S/MIME encapsulation.
   A security label can be included in the signed attributes of any
   SignedData object.  A security label attribute may be included in
   either the inner signature, outer signature, or both.  The syntax and
   processing rules for security labels are described in RFC 2634 [ESS].

   The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
   'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
   document are to be interpreted as described in RFC 2119 [MUSTSHOULD].

1.1 Information Classification Policies

   Information is an asset, but not all information has the same value
   for a business.  Not all information needs to be protected as
   strongly as other information.

   Research and development plans, marketing strategies and
   manufacturing quality specifications developed and used by a company
   provide competitive advantage.  This type of information needs




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


   stronger protective measures than other information, which if
   disclosed or modified, would cause moderate to severe damage to the
   company.

   Other types of information such as internal organization charts,
   employee lists and policies may need little or no protective measures
   based on value the organization places on it.

   A corporate information classification policy defines how its
   information assets are to be protected.  It provides guidance to
   employees on how to classify information assets.  It defines how to
   label and protect an asset based on its classification and state
   (e.g., facsimile, electronic transfer, storage, shipping, etc.).

1.2 Access Control and Security Labels

   "Access control" is a means of enforcing authorizations.  There are a
   variety of access control methods that are based on different types
   of policies and rely on different security mechanisms.

   - Rule based access control is based on policies that can be
     algorithmically expressed.

   - Identity based access control is based on a policy which applies
     explicitly to an individual person or host entity, or to a defined
     group of such entities.  Once identity has been authenticated, if
     the identity is verified to be on the access list, then access is
     granted.

   - Rank base access control is based on a policy of hierarchical
     positions in an organization.  It is based on who you are in the
     company structure.  A rank-based policy would define what
     information that the position of Partner or Senior Consultant could
     access.

   - Role based access control is based on a policy of roles in an
     organization.  It may or may not be hierarchical.  It is based on
     who you are in the company.  The role-based policy would define
     what information that the role of Database Administrator, Network
     Administrator, Mailroom Clerk or Purchaser could access.

   Rule, rank and role-based access control methods can rely on a
   security label as the security mechanism to convey the sensitivity or
   classification of the information.  When processing an S/MIME
   encapsulated message, the sensitivity information in the message's
   security label can be compared with the recipient's authorizations to
   determine if the recipient is allowed to access the protected
   content.



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


   An S/MIME security label may be included as a signed attribute in the
   inner (or only) signature or the outer signature.  In the case of a
   triple-wrapped message as defined in RFC 2634, the inner signature
   would be used for access control decisions related to the plaintext
   original content, while the outer signature would be used for access
   control decisions related to the encrypted message.

1.3 User Authorizations

   Users need to be granted authorizations to access information that
   has been classified by an authority.  The sending and receiving
   agents need to be able to securely determine the user's
   authorizations for access control processing.

   X.509 [X.509] and the Internet profile for X.509 certificates
   [CERTCRL] do not define the means to represent and convey
   authorizations in a certificate.

   X.501 [X.501] defines how to represent authorization in the form of a
   clearance attribute.  The clearance attribute identifies the security
   policy in force to which a list of possible classifications and
   security categories relates.

   X.501 also notes two means for binding the clearance to a named
   entity: an Attribute Certificate and a Certificate extension field
   (e.g., within the subjectDirectoryAttribute extension).

   RFC 3281 [AC509] defines a profile of X.509 Attribute Certificate
   (AC) suitable for use with authorization information within Internet
   Protocols.  One of the defined attributes is Clearance, which carries
   clearance (security labeling) information about the AC owner.  The
   syntax for Clearance is imported from X.501.

2. Developed Examples

2.1 Classification Policies

   The following describes the information classification policies in
   effect at 3 companies.

2.1.1 Amoco Corporation

   The description for the Amoco information classification policy was
   taken from the Amoco Computer Security Guidelines.  Amoco classifies
   its information assets based on confidentiality and integrity and
   defines 3 hierarchical classifications for each.  The confidentiality





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


   and integrity polices are independent, so either or both may be
   applied to the information.  Amoco also defines an availability
   classification for time critical information.

   HIGHLY CONFIDENTIAL - Information whose unauthorized disclosure will
   cause the company severe financial, legal or reputation damage.
   Examples: Certain acquisitions, bid economics, negotiation
   strategies.

   CONFIDENTIAL - Information whose unauthorized disclosure may cause
   the company financial, legal, or reputation damage.  Examples:
   Employee Personnel & Payroll Files, some interpreted Exploration
   Data.

   GENERAL - Information that, because of its personal, technical, or
   business sensitivity is restricted for use within the company.
   Unless otherwise classified, all information within Amoco is in this
   category.

   MAXIMUM - Information whose unauthorized modification and destruction
   will cause the company severe financial, legal, or reputation damage.

   MEDIUM - Information whose unauthorized modification and destruction
   may cause the company financial, legal, or reputation damage.
   Examples: Electronic Funds, Transfer, Payroll, and Commercial Checks.

   MINIMUM - Although an error in this data would be of minimal
   consequence, this is still important company information and
   therefore will require some minimal controls to ensure a minimal
   level of assurance that the integrity of the data is maintained.
   This applies to all data that is not placed in one of the above
   classifications.  Examples: Lease Production Data, Expense Data,
   Financial Data, and Exploration Data.

   CRITICAL - It is important to assess the availability requirements of
   data, applications and systems.  A business decision will be required
   to determine the length of unavailability that can be tolerated prior
   to expending additional resources to ensure the information
   availability that is required.  Information should be labeled
   "CRITICAL" if it is determined that special procedures should be used
   to ensure its availability.

2.1.2 Caterpillar, Inc.

   The description for the Caterpillar information classification policy
   is taken from the Caterpillar Information Protection Guidelines.
   Caterpillar classifies its information assets based on
   confidentiality and defines 4 hierarchical classifications.



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


   Caterpillar Confidential Red - Provides a significant competitive
   advantage.  Disclosure would cause severe damage to operations.
   Relates to or describes a long-term strategy or critical business
   plans.  Disclosure would cause regulatory or contractual liability.
   Disclosure would cause severe damage to our reputation or the public
   image.  Disclosure would cause a severe loss of market share or the
   ability to be first to market.  Disclosure would cause a loss of an
   important customer, shareholder, or business partner.  Disclosure
   would cause a long-term or severe drop in stock value.  Strong
   likelihood somebody is seeking to acquire this information.

   Caterpillar Confidential Yellow - Provides a competitive advantage.
   Disclosure could cause moderate damage to the company or an
   individual.  Relates to or describes an important part of the
   operational direction of the company over time.  Important technical
   or financial aspects of a product line or a business unit.
   Disclosure could cause a loss of Customer or Shareholder confidence.
   Disclosure could cause a temporary drop in stock value.  A likelihood
   that somebody could seek to acquire this information.

   Caterpillar Confidential Green - Might provide a business advantage
   over those who do not have access to the same information.  Might be
   useful to a competitor.  Not easily identifiable by inspection of a
   product.  Not generally known outside the company or available from
   public sources.  Generally available internally.  Little competitive
   interest.

   Caterpillar Public - Would not provide a business or competitive
   advantage.  Routinely made available to interested members of the
   General Public.  Little or no competitive interest.

2.1.3 Whirlpool Corporation

   The description for the Whirlpool information classification policy
   is taken from the Whirlpool Information Protection Policy.  Whirlpool
   classifies its information assets based on confidentiality and
   defines 3 hierarchical classifications.  The policy states that:

   "All information generated by or for Whirlpool, in whatever form,
   written, verbal, or electronic, is to be treated as WHIRLPOOL
   INTERNAL or WHIRLPOOL CONFIDENTIAL.  Classification of information in
   either category depends on its value, the impact of unauthorized
   disclosure, legal requirements, and the manner in which it needs to
   be used by the company.  Some WHIRLPOOL INTERNAL information may be
   authorized for public release."






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


   WHIRLPOOL CONFIDENTIAL - A subset of Whirlpool Internal information,
   the unauthorized disclosure or compromise of which would likely have
   an adverse impact on the company's competitive position, tarnish its
   reputation, or embarrass an individual.  Examples: Customer,
   financial, pricing, or personnel data; merger/acquisition, product,
   or marketing plans; new product designs, proprietary processes and
   systems.

   WHIRLPOOL INTERNAL - All forms of proprietary information originated
   or owned by Whirlpool, or entrusted to it by others.  Examples:
   Organization charts, policies, procedures, phone directories, some
   types of training materials.

   WHIRLPOOL PUBLIC - Information officially released by Whirlpool for
   widespread public disclosure.  Example: Press releases, public
   marketing materials, employment advertising, annual reports, product
   brochures, the public web site, etc.

   The policy also states that privacy markings are allowable.
   Specifically:

   For WHIRLPOOL INTERNAL, additional markings or caveats are optional
   at the discretion of the information owner.

   For WHIRLPOOL CONFIDENTIAL, add additional marking or caveats as
   necessary to comply with regulatory or heightened security
   requirements.  Examples: MAKE NO COPIES, THIRD PARTY CONFIDENTIAL,
   ATTORNEY-CLIENT PRIVILEGED DOCUMENT, DISTRIBUTION LIMITED TO ____,
   COVERED BY A NON-ANALYSIS AGREEMENT.

2.2 S/MIME Classification Label Organizational Examples

   RFC 2634 [ESS] defines the ESSSecurityLabel syntax and processing
   rules.  This section builds upon those definitions to define detailed
   example policies.

2.2.1 Security Label Components

   The examples are detailed using the various components of the
   eSSSecurityLabel syntax.

2.2.1.1 Security Policy Identifier

   A security policy is a set of criteria for the provision of security
   services.  The eSSSecurityLabel security-policy-identifier is used to
   identify the security policy in force to which the security label
   relates.  It indicates the semantics of the other security label
   components.



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


   For the example policies, the following security policy object
   identifiers are defined:

   -- S/MIME Working Group Object Identifier Registry
   id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
                                  rsadsi(113549) pkcs(1) pkcs-9(9) 16 }

   -- S/MIME Test Security Policy Arc
   id-tsp  OBJECT IDENTIFIER ::= { id-smime 7 }

   -- Test Security Policies
   id-tsp-TEST-Amoco          OBJECT IDENTIFIER ::= { id-tsp 1 }
   id-tsp-TEST-Caterpillar    OBJECT IDENTIFIER ::= { id-tsp 2 }
   id-tsp-TEST-Whirlpool      OBJECT IDENTIFIER ::= { id-tsp 3 }

2.2.1.2 Security Classification

   The security classification values and meanings are defined by the
   governing company policies.  The security-classification values
   defined are hierarchical and do not use integers 0 through 5.

   Amoco-SecurityClassification ::= INTEGER {
     amoco-general (6),
     amoco-confidential (7),
     amoco-highly-confidential (8) }

   Caterpillar-SecurityClassification ::= INTEGER {
     caterpillar-public (6),
     caterpillar-green (7),
     caterpillar-yellow (8),
     caterpillar-red (9) }

   Whirlpool-SecurityClassification ::= INTEGER {
     whirlpool-public (6),
     whirlpool-internal (7),
     whirlpool-confidential (8) }

2.2.1.3 Privacy Mark

   Privacy marks are specified the Whirlpool policy.  The policy
   provides examples of possible markings but others can be defined by
   users as necessary (though no guidance is given).  The Whirlpool
   policy provides the following examples: MAKE NO COPIES, THIRD PARTY
   CONFIDENTIAL, ATTORNEY-CLIENT PRIVILEGED DOCUMENT, DISTRIBUTION
   LIMITED TO ____, and COVERED BY A NON-ANALYSIS AGREEMENT.






Nicolls                      Informational                      [Page 7]

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: (847) 763-2370
   EMail: wnicolls@forsythesolutions.com










































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]