draft-ietf-pkix-usergroup-01.txt

来自「PKIX的RFC英文文档」· 文本 代码 · 共 785 行 · 第 1/2 页

5.1 Web Server with Client Certificates

   In one particular web-based system which depends upon client
   certificates for authentication, there are four distinct actions that
   have to take place before a user is fully enrolled (i.e.  before
   client certificate authorization can take place automatically).
   First, a user must have a client certificate issued.  Second, the
   administrator must create an account for the user.  Third, the
   administrator of the web service must issue a userid and password for
   that service account to the user.  Finally, the user connects to a
   secure web page which does a client certificate SSL/TLS exchange.

   If the web server has a mapping between a userid and this certificate
   already the interaction is complete and the access rights of the
   mapped userid are used when considering access to the resources.
   Otherwise, the web server prompts for a userid and password which is
   then validated.  If valid, the web server stores the userid/
   certificate mapping for future reference as above.  This last step,
   in conjunction with the client certificate exchange results in a
   semi-permanent mapping between the client certificate and the userid.

   In later interactions between client and server, the client may do
   automatic client side authentication using its certificate-based
   credential.  The user is granted access to whatever resources the
   access control system permissions allow for the userid which is
   associated with the client (user) certificate.

   In a UserGroupName alternative for this, the user is issued a
   credential consisting of an X.509 certificate with an appropriate
   UserGroupName SANE and its associated private key.  The credential
   can be issued in many ways including at least through a certificate
   signing request, central generation (e.g.  a PKCS12 blob), or through
   the distribution of a hardware token.  The administrator must also
   still create an account on the service.  Upon connection to the
   protected server, the userid (and/or the groups field if permitted by
   policy) is extracted from the validated client certificate and used
   as the basis for access control decisions.  The process of issuing a
   PKCS12 blob (containing certificate and private key) or hardware
   token is roughly equivalent to the single step of issuing a userid
   and password as described above.

   As an alternative to having an administrator explicitly create an
   account for a user, the policy of the web server could allow an
   account to be created based on the contents of the group field of the
   UserGroupName.  In other words, the web server consults the group
   field once during the first interaction between the user and the
   server.  If the interaction is authenticated and policy authorizes
   it, the web server can create an account specific to the userid



StJohns                  Expires March 26, 2003                 [Page 8]

Internet-Draft             PKIX UserGroupName             September 2002


   contained within the user certificate.  The groups field is not
   consulted once the server creates the account.

6. Security Considerations

   The use of the UserGroupName in most situations has roughly the same
   level of threat as that for any X.509 certificate and the Security
   Considerations text in [RFC3280] is applicable.  However, the use of
   the groups element of the UserGroupName may have some unforeseen side
   effects in certain systems.

   The user tags (along with the private keys of the certificates) are
   just credentials.  They can be used to prove the identity of a
   client, but don't of themselves grant a client access to data or
   other resources.  An access control system is used to map credentials
   to rights.  Revocation of access of a client to a resource is as
   simple as removing or changing the access control entry and doesn't
   necessarily require the use of a Certificate Revocation List (CRL) to
   revoke the certificate.  Indeed, the revocation of the certificate
   may be undesirable as the removal of access may be only temporary.

   However, the use of group tags is problematic in systems which do not
   consider Certificate Revocation Lists as part of their path
   validation processing.  Since group access by definition covers a
   group of people, its difficult or impossible to remove access for a
   single member of the group without removing the user from the group.
   If the group information is encoded in the certificate, use of CRLs
   is pretty much mandatory.

   One possible approach where groups are desired, but CRLs are not
   available is to not encode the group information within the
   certificate.  Instead, do the user to group mapping as part of the
   access control processing (ala Unix).  In that manner, a user could
   be deleted from a group simply by updating the user to group mappings
   on all accepting systems.  Another related approach might be to have
   a user and group hotlist where you would add a user only if you
   wanted to remove them from a group that's listed in the client
   certificate.

7. Design Discussion

   There are many possible ways of accomplishing the goals of directly
   encoding user and group information within a certificate.  This
   section provides some insight into the author's reasoning to adopt
   the otherName approach.






StJohns                  Expires March 26, 2003                 [Page 9]

Internet-Draft             PKIX UserGroupName             September 2002


7.1 Attribute Certificate

   Attribute certificates (ACs) were offered by a couple of members of
   the PKIX community as one solution for this problem.  The argument
   was made that attribute certificates were the appropriate approach
   for things that looked like authorization tokens.

   This approach was rejected for a couple of reasons.  First, that ACs
   had no defined mechanism for encoding the user and group information.
   This otherName extension would still be required to provide the
   encoding.  Second, ACs were neither in wide use, nor widely
   understood.  Without this knowledge, there is a lack of software on
   both the issuer and acceptor ends which could deal with the ACs.
   Third, the author didn't completely agree with the argument that
   userid and group credentials are authorization tokens.  Userid and
   group assignments for most users tend to be fairly static.  The
   author, for example, held the same userid and the same group
   assignments for over four years at his previous job.  (Except, see
   Section 6 above.)

   If ACs gain acceptability, there should be no bars to incorporating
   this otherName extension as one of the possible attributes allowed
   within an AC.

7.2 Certificate Extension

   The approach of encoding the user and group information as a new
   CertificateExtension was initially attractive for a number of
   reasons.  First, most software and toolkits had at least rudimentary
   support for new extensions.  Second, the actual ASN1 encoding of the
   information was a bit less clumsy than if encoded as an otherName.

   This option was also rejected when the author tried to consider the
   interactions between this extension, the Subject and IssuerNames, and
   the Subject and IssuerAltName extensions.  Having a third place for
   possibly authoritative name information might make the rules for
   resolving which name should be used for various authorization
   activities a bit difficult.

7.3 otherName GeneralName type

   Encoding the user and group information as an otherName appears to be
   the mostly right choice.  It doesn't add additional extensions which
   might further conflict with the SubjectName field and SubjectAltName
   extension.  The usage is well within the appropriate field of use for
   the otherName type.

References



StJohns                  Expires March 26, 2003                [Page 10]

Internet-Draft             PKIX UserGroupName             September 2002


   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2246]  Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A.
              and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246,
              January 1999.

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


Author's Address

   Michael StJohns
   Network Associates Labs
   15204 Omega Drive
   Rockville, MD  20850
   USA

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

Appendix A. ASN.1 Definitions

   N.B.  Any assignments within this section should not be relied upon
   until and if this document is published either as an experimental RFC
   or until it enters the standards track.

A.1 1988 Module


   PKIXusergroup {iso(1) identified-organization(3) dod(6)
          internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
          id-mod-user-group (20) }

   DEFINITIONS EXPLICIT TAGS ::=

      BEGIN

      -- EXPORTS ALL --

      IMPORTS




StJohns                  Expires March 26, 2003                [Page 11]

Internet-Draft             PKIX UserGroupName             September 2002


           id-pkix, AttributeType, UTF8String
                   FROM PKIX1Explicit88 {iso(1) identified-organization(3)
                   dod(6) internet(1) security(5) mechanisms(5) pkix(7)
                   id-mod(0) id-pkix1-explicit-88(1)}

      -- Object Identifiers

      -- Externally defined OIDs

      -- Arc for other name forms
      id-on   OBJECT IDENTIFIER ::= { id-pkix 8 }

      -- userGroupName

      id-on-userGroup   AttributeType ::= { id-on 2 }


      UserGroupName ::=     SEQUENCE {
              domain     UTF8String,
              user       UTF8String,
              groups     SEQUENCE OF UTF8String OPTIONAL
      }

   END



























StJohns                  Expires March 26, 2003                [Page 12]

Internet-Draft             PKIX UserGroupName             September 2002


A.2 Notional ASN.1 Encoding

   The following represents how a UserGroupName otherName would be
   encoded within an SubjectAltName Extension.  The notation "'[" means
   to encode the enclosed items and return the octets.

   [SEQUENCE                              -- Extension
     OID            id-ce-subjectAltName  -- extnID
     BOOLEAN        true                  -- critical
     OCTET STRING                         -- extnValue
        -- Encode the following and provide as value for OCTET STRING
      '[SEQUENCE                          -- GeneralNames
         [0                               -- otherName type tag
           [SEQUENCE                      -- otherName
             OID    id-on-userGroup       -- type-id
             [0
               [SEQUENCE                  -- UserGroupName
                 UTF8String  'tislabs.com' -- domain
                 UTF8String  'stjohns'    -- userid
                 [SEQUENCE OF             -- groups
                   UTF8String  'system'
                   UTF8String  'atg'
                 ]
               ]
             ]
           ]
         ]
       ]'
   ]






















StJohns                  Expires March 26, 2003                [Page 13]

Internet-Draft             PKIX UserGroupName             September 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.



















StJohns                  Expires March 26, 2003                [Page 14]