[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 4534

Internet Engineering Task Force
INTERNET-DRAFT                                            A Colegrove
                                                             H Harney
draft-ietf-msec-policy-token-sec-06.txt                  SPARTA, Inc.
Expires:  July 23, 2006                                  January 2006


                   Group Security Policy Token v1




Status of this memo



  By submitting this Internet-Draft, each author represents that any
  applicable patent or other IPR claims of which he or she is aware
  have been or will be disclosed, and any of which he or she becomes
  aware will be disclosed, in accordance with Section 6 of BCP 79.

  Internet-Drafts are working documents of the Internet Engineering
  Task Force (IETF), its areas, and its working groups.  Note
  that other groups may also distribute working documents as
  Internet-Drafts.

  Internet-Drafts are draft documents valid for a maximum of six months
  and may be updated, replaced, or obsoleted by other documents at
  any time.  It is inappropriate to use Internet-Drafts as reference
  material or to cite them other than as "work in progress."

  The list of current Internet-Drafts can be accessed at
  http://www.ietf.org/1id-abstracts.html

  The list of Internet-Draft Shadow Directories can be accessed at
  http://www.ietf.org/shadow.html


Abstract


    The Group Security Policy Token is a structure used to
    specify the security policy and configurable parameters
    for a cryptographic group, such as a secure multicast
    group.  Because the security of a group is comprised of
    the totality of multiple security services, mechanisms, and
    attributes throughout the communications infrastructure,
    an authenticatable representation of the features that
    must be supported throughout the system is needed to ensure
    consistent security.  This document specifies the structure


INTERNET-DRAFT       Group Security Policy Token v1      January 2006

    of such a token.




















































Colegrove and Harney                                         [Page 2]

INTERNET-DRAFT       Group Security Policy Token v1      January 2006

Contents

1 Introduction                                                      5

2 Token Creation and Receipt                                        6
3 The Policy Token                                                  6
  3.1 Token Identifiers . . . . . . . . . . . . . . . . . . . . .   8
  3.2 Registration Policy . . . . . . . . . . . . . . . . . . . .   8
  3.3 Rekey Policy  . . . . . . . . . . . . . . . . . . . . . . .   9
  3.4 Group Data Policy . . . . . . . . . . . . . . . . . . . . .  10

4 Security Considerations                                          10
5 IANA Considerations                                              10

6 References                                                       11
  6.1 Normative References  . . . . . . . . . . . . . . . . . . .  11
  6.2 Non-Normative References  . . . . . . . . . . . . . . . . .  12

7 Acknowledgments                                                  12
A APPENDIX A -- Core Policy Token ASN.1 Module                     13

B APPENDIX B -- GSAKMPv1 Base Policy                               15
  B.1 GSAKMPv1 Registration Policy  . . . . . . . . . . . . . . .  15
    B.1.1 Authorization . . . . . . . . . . . . . . . . . . . . .  15
    B.1.2 AccessControl . . . . . . . . . . . . . . . . . . . . .  17
    B.1.3 JoinMechanisms  . . . . . . . . . . . . . . . . . . . .  17
        B.1.3.1 alaCarte  . . . . . . . . . . . . . . . . . . . .  18
        B.1.3.2 suite . . . . . . . . . . . . . . . . . . . . . .  19
    B.1.4Transport  . . . . . . . . . . . . . . . . . . . . . . .  20
  B.2 GSAKMPv1 Registration ASN.1 Module  . . . . . . . . . . . .  20
  B.3 GSAKMPv1 De-Registration Policy . . . . . . . . . . . . . .  23
  B.4 GSAKMPv1 De-Registration ASN.1 Module . . . . . . . . . . .  24
  B.5 GSAKMPv1 Rekey Policy . . . . . . . . . . . . . . . . . . .  24
    B.5.1 Rekey Authorization . . . . . . . . . . . . . . . . . .  25
    B.5.2 Rekey Mechanisms  . . . . . . . . . . . . . . . . . . .  25
    B.5.3 Rekey Event Definition  . . . . . . . . . . . . . . . .  26
    B.5.4 Rekey Methods . . . . . . . . . . . . . . . . . . . . .  27
        B.5.4.1 Rekey Method NONE . . . . . . . . . . . . . . . .  27
        B.5.4.2 Rekey Method GSAKMP LKH . . . . . . . . . . . . .  27
    B.5.5 Rekey Interval  . . . . . . . . . . . . . . . . . . . .  28
    B.5.6 Rekey Reliability . . . . . . . . . . . . . . . . . . .  28
        B.5.6.1 Rekey Reliability Mechanism None  . . . . . . . .  28
        B.5.6.2 Rekey Reliability Mechanism Resend  . . . . . . .  28
        B.5.6.3 Rekey Reliability Mechanism Post  . . . . . . . .  29
    B.5.7 Distributed Operation Policy  . . . . . . . . . . . . .  29
        B.5.7.1 No Distributed Operation  . . . . . . . . . . . .  29
        B.5.7.2 Autonomous Distributed Mode . . . . . . . . . . .  30
  B.6 GSAKMPv1 Rekey Policy ASN.1 Module  . . . . . . . . . . . .  30
C APPENDIX C -- Data SA Policy                                     33
  C.1 Generic Data Policy . . . . . . . . . . . . . . . . . . . .  33
  C.2 Generic Data Policy ASN.1 Module  . . . . . . . . . . . . .  34


Colegrove and Harney                                         [Page 3]

INTERNET-DRAFT       Group Security Policy Token v1      January 2006

D APPENDIX D -- Change History (To Be Removed from RFC)            34
  D.1 Changes from Group Policy Token v-00 to v-01, December 2004  34
  D.2 Changes from Group Policy Token v-01 to v-02, March 2005  .  35
  D.3 Changes from Group Policy Token v-02 to v-03, July 2005 . .  35
  D.4 Changes from Group Policy Token v-03 to v-04, September 2005 35
  D.5 Changes from Group Policy Token v-04 to v-05, December 2005  35
  D.6 Changes from Group Policy Token v-05 to v-06, January 2006   35

Authors Addresses                                                  37
Full Copyright Statement                                           37

IPR Considerations                                                 37









































Colegrove and Harney                                         [Page 4]

INTERNET-DRAFT       Group Security Policy Token v1      January 2006

1 Introduction


  The Multicast Group Security Architecture [RFC3740] defines the
  security infrastructure to support secure group communications.  The
  Policy Token assumes this architecture in its definition.  It defines
  the enforceable security parameters for a Group Secure Association.

  The Policy Token is a verifiable data construct signed by the group
  owner, the entity with the authorization to create security policy.
  The group controllers in a group will use the policy token to ensure
  that the mechanisms used to secure the group are correct and to
  enforce the access control rules for joining members.  The group
  members, who may contribute data to the group or access data from the
  group, will use the policy token to ensure that the group is owned by
  a trusted authority.  Also, the members may want to verify that the
  access control rules are adequate to protect the data that the member
  is submitting to the group.

  The Policy Token is specified in ASN.1 [X.208] and is to be DER
  [X.660] encoded.  This specification ability allows the token to
  easily import group definitions that span different applications and
  environments.  ASN.1 allows the token to specify branches that can
  be used by any multicast security protocol.  Any group can use this
  policy token structure to specify the use of multiple protocols in
  securing the group.

  Care was taken in this specification to provide a core level of token
  specificity that would allow ease of extensibility and flexibility
  in supporting mechanisms.  This was done by using the following
  abstracted construct:



    Mechanism ::= SEQUENCE {
      mechanismIdentifier  OBJECT IDENTIFIER,
      mechanismParameters OCTET STRING
    }


  This construct will allow the use of group mechanisms specified in
  other documents with the Policy Token.

  The Policy Token is structured to reflect the MSEC Architecture
  layers for a Group Security Association.  Each of the architectural
  layers is identified and given a branch in the "Core" token.
  This allows a high degree of flexibility for future protocol
  specifications at each architectural layer without the need to change
  the "Core" policy token, which can then act as a single point of
  reference for defining secure groups using any mix of protocols for
  any number of environments.


Colegrove and Harney                                           [Page 5]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006

2 Token Creation and Receipt


  At the time of group creation or whenever the policy of the group is
  updated, the Group Owner will create a new policy token.

  To ensure authenticity of the specified policy, the Token MUST be
  signed by the Group Owner.  The signed token MUST be in accordance
  with the CMS [RFC 3852] SignedData type.

  The content of the SignedData is the token itself.  It is represented
  with the ContentType object identifier of



    id-ct-msec-token    OBJECT IDENTIFIER ::= {TBD}


  The CMS sid value of the SignerInfo, which identifies the public key
  needed to validate the signature, MUST be that of the Group Owner.

  The signedAttrs field MUST be present.  In addition to the minimally
  required fields of signedAttrs, the signing-time attribute MUST be
  present.

  Upon receipt of a Policy Token, the recipient MUST check that


   -  the Group Owner, as identified by the sid in the SignerInfo, is
      the expected entity

   -  the signing-time value is more recent than the signing-time value
      seen in a previously received Policy Token for that group, or the
      Policy Token is the first token seen by the recipient for that
      group.

   -  the processing of the signature successfully validates in
      accordance with RFC 3852

   -  the specified security and communication mechanisms (or at least
      one mechanism of each choice) are supported and are in compliance
      with the recipient's local policy.


3 The Policy Token


  The structure of the Policy Token is as follows:





Colegrove and Harney                                           [Page 6]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006

    Token ::= SEQUENCE {
      tokenInfo     TokenID,
      registration  SEQUENCE OF Registration,
      rekey         SEQUENCE OF GroupMngmtProtocol,
      data          SEQUENCE OF DataProtocol
    }



  tokenInfo provides information about the instance of the Policy
      Token (PT).

  registration provides a list of acceptable registration and
      deregistration policy and mechanisms that may be used to manage
      member-initiated joins and departures from a group.  A NULL
      sequence indicates that the group does not support registration
      and deregistration of members.  A member MUST be able to support
      at least one set of Registration mechanisms in order to join
      the group.  When multiple mechanisms are present, a member MAY
      use any of the listed methods.  The list is ordered in terms of
      Group Owner preference.  A member MUST choose the highest listed
      mechanism that local policy supports.

  rekey provides the rekey protocols that will be used in managing
      the group.  The member MUST be able to accept one of the types
      of rekey messages listed.  The list is ordered in terms of
      Group Owner preference.  A member MUST choose the highest listed
      mechanism that local policy supports.

  data provides the applications used in the communications between
      group members.  When multiple applications are provided, the
      order of the list implies the order of encapsulation of the data.
      A member MUST be able to support all the listed applications and
      if any choices of mechanisms are provided per application, the
      member MUST support at least one of the mechanisms.


  For the registration, rekey, and data fields, implementations
  encountering unknown protocol identifiers MUST handle this gracefully
  by providing indicators that an unknown protocol is among the
  sequence of permissible protocols.  If the unknown protocol is the
  only allowable protocol in the sequence, then the implementation
  cannot support that field, and the member cannot join the group.
  It is a matter of local policy whether a join is permitted when an
  unknown protocol exists among the allowable, known protocols.

  Protocols in addition to registration, rekey, and data SHOULD NOT
  be added to subsequent versions of this Token unless the MSEC
  architecture changes.

  Each data field of the PT is specified further in the following
  sections.

Colegrove and Harney                                           [Page 7]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006

3.1 Token Identifiers


  tokenInfo explicitly identifies a version of the Policy Token for a
      particular group.  It is defined as



    TokenID ::= SEQUENCE {
      tokenDefVersion INTEGER (1),
      groupName       OCTET STRING,
      edition         INTEGER OPTIONAL
    }


  tokenDefVersion is the version of the Group Policy Token
      Specification.  This specifications (v1) is represented as one
      (1).  Changes to the structure of the Group Security Policy Token
      will require an update to this field.

  groupName is the identifier of the group and MUST be unique relative
      to the Group Owner.

  edition is an optional INTEGER indicating the sequence number of the
      PT. If edition is present, group entities MUST accept a PT only
      when the value is greater than the last value seen in a valid PT
      for that group.


  The type LifeDate is also defined to provide standard methods of
  indicating timestamps and intervals in the Tokens.


    LifeDate ::= CHOICE {
      gt       GeneralizedTime,
      utc      UTCTime,
      interval INTEGER
    }


3.2 Registration Policy


  The registration SA is defined in the MSEC Architecture.  During
  registration, a prospective group member and the group controller
  will interact to give the group member access to the keys and
  information it needs to join the group and participate in the group
  data SA.

  The deregistration piece allows a current group member to notify the
  GC/KS that it will no longer be participating in the data SA.


Colegrove and Harney                                           [Page 8]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006

    Registration ::= SEQUENCE {
      register    GroupMngmtProtocol,
      de-register GroupMngmtProtocol
    }



  The protocol for registration and de-registration are each specified
  as


    GroupMngmtProtocol ::= CHOICE {
      none      NULL,
      supported Protocol
    }

    Protocol ::= SEQUENCE {
      protocol      OBJECT IDENTIFIER,
      protocolInfo  OCTET STRING
    }


  For example, register might be specified as the GSAKMP [HMCG]
  registration protocol.  The OBJECT IDENTIFIER TBS would be followed
  by the parameters used in GSAKMP registration as specified in
  appendix B.1.


3.3 Rekey Policy


  The Rekey SA is defined in the MSEC Architecture.  During the Rekey
  of a group, several changes can potentially be made:


   -  refresh/change group protection keys,

   -  update the Policy Token,

   -  change the group membership.


  During Rekey, the membership of the group can be modified as well as
  refreshing the group traffic protection keys and updating the Policy
  Token.

  This field is also specified as a sequence of protocols that will be
  used by the GC/KS.





Colegrove and Harney                                           [Page 9]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006

3.4 Group Data Policy


  The Data SA is the ultimate consumer of the group keys.  The data
  field will indicate the keys and mechanisms that are to be used in
  communications between group members.  There are several protocols
  that could make use of group keys, ranging from simple security
  applications that only need key for encryption and/or integrity
  protection to more complex configurable security protocols such as
  IPsec and SRTP. The sequencing of the Data SA mechanisms are from
  "inside" to "outside".  That is, the first Data SA defined in a
  policy token must act on the raw data.  Any data SA specified after
  that will be applied in turn.



    DataProtocol ::= Protocol


4 Security Considerations


  This document specifies the structure for a Group Policy Token.  As
  such, the structure as received by a group entity must be verifiably
  authentic.  This Policy Token uses CMS to apply authentication
  through digital signatures.  The security of this scheme relies
  upon a secure CMS implementation, choice of signature mechanism
  of appropriate strength for the group using the Policy Token,
  and secure, sufficiently strong keys.  Additionally, it relies
  upon knowledge of a well-known Group Owner as the root of policy
  enforcement.

  Furthermore, while the Group Owner may list alternate mechanisms
  for various functions, the group is only as strong as the weakest
  accepted mechanisms.  As such, the Group Owner is responsible for
  providing only acceptable security mechanisms.



5 IANA Considerations


  The following object identifiers should be assigned:


   -  id-ct-msec-token OBJECT IDENTIFIER ::= TBD

   -  id-securitySuiteOne OBJECT IDENTIFIER ::= TBD

   -  id-GSAKMPv1RegistrationProtocol OBJECT IDENTIFIER::= TBD

   -  id-GSAKMPv1DeRegistrationProtocol OBJECT IDENTIFIER::= TBD

Colegrove and Harney                                          [Page 10]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006

   -  id-GSAKMPv1Rekey OBJECT IDENTIFIER::= TBD

   -  id-rekeyNone OBJECT IDENTIFIER ::= TBD

   -  id-rekeyMethodGSAKMPLKH OBJECT IDENTIFIER ::= TBD

   -  id-reliabilityNone OBJECT IDENTIFIER ::= TBD

   -  id-reliabilityResend OBJECT IDENTIFIER ::= TBD

   -  id-reliabilityPost OBJECT IDENTIFIER ::= TBD

   -  id-subGCKSSchemeNone OBJECT IDENTIFIER ::= TBD

   -  id-subGCKSSchemeAutonomous OBJECT IDENTIFIER ::= TBD

   -  id-genericDataSA OBJECT IDENTIFIER ::= TBD



  The Group Security Policy Token can be extended through
  specification.  Extensions in the form of objects can be registered
  through IANA. Extensions requiring changes to the protocol structure
  will require an update to the tokenDefVersion field of the TokenID
  (see section 3.1).


6 References


  The following references were used in the preparation of this
  document.


6.1 Normative References


  [HMCG] H. Harney, U. Meth, A. Colegrove, and G. Gross, "GSAKMP",
  draft-ietf-msec-gsakmp-sec-10.txt, RFC Editor Queue, May 2005.

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

  [RFC 3852] R. Housley, Cryptographic Message Syntax, RFC 3825, July
  2004.

  [X.208] Recommendation X.209, Specification of Abstract Syntax
  Notation One (ASN.1), 1988.

  [X.660] Recommendation X.660, Information Technology ASN.1 Encoding


Colegrove and Harney                                          [Page 11]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006

  Rules:  Specification of Basic Encoding Rules (BER), Canonical
  Encoding Rules (CER), and Distinguished Encoding Rules (DER), 1997.



6.2 Non-Normative References


  [HCLM00] H. Harney, A. Colegrove, P. Lough, and U. Meth, "GSAKMP
  Token Specification", draft-ietf-msec-tokenspec-sec-00.txt.

  [RFC 3711] M. Baugher, D. McGrew, M. Naslund, E. Carrara, and K.
  Norrman, "The Secure Real-Time Transport Protocol (SRTP)", RFC 3711,
  March 2004.

  [RFC 3740] T. Hardjono and B. Weis, "The Multicast Group Security
  Architecture", RFC 3740, March 2004.

  [HCM01] H. Harney, A. Colegrove, P. McDaniel, "Principles of Policy
  in Secure Groups", Proceedings of Network and Distributed Systems
  Security 2001 Internet Society, San Diego, CA, February 2001

  [HHMCD01] , Thomas Hardjono, Hugh Harney, Pat McDaniel, Andrea
  Colgrove, Pete Dinsmore, Group Security Policy Token:  Definition and
  Payloads', draft-ietf-msec-gspt-00.txt, Expired.


7 Acknowledgments


  The following individuals deserve recognition and thanks for their
  contributions which have greatly improved this specification:  Uri
  Meth whose knowledge of GSAKMP and tokens was greatly appreciated
  as well as his help in getting this document submitted; Peter Lough,
  Thomas Hardjono, Patrick McDaniel, and Pete Dinsmore for their work
  on earlier versions of policy tokens; George Gross for the impetus to
  have a well-specified, extensible policy token; and Rod Fleischer for
  catching implementation issues.















Colegrove and Harney                                          [Page 12]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006

A APPENDIX A -- Core Policy Token ASN.1 Module


  PolicyToken -- {TBD}

  DEFINITIONS IMPLICIT TAGS ::=

  BEGIN

  Token ::= SEQUENCE {
    tokenInfo    TokenID,
    registration SEQUENCE OF Registration,
    rekey        SEQUENCE OF GroupMngmtProtocol,
    data         SEQUENCE OF DataProtocol
  }

  ------------------------------------------------------------
      -- Token ID

  TokenID ::= SEQUENCE {
    tokenDefVersion INTEGER (1),     -- Group Security Policy Token v1
    groupName       OCTET STRING,
    edition         INTEGER OPTIONAL
  }

  LifeDate ::= CHOICE {
    gt       GeneralizedTime,
    utc      UTCTime,
    interval INTEGER
  }

  ------------------------------------------------------------
      -- Registration

  Registration ::= SEQUENCE {
    register    GroupMngmtProtocol,
    de-register GroupMngmtProtocol
  }

  ------------------------------------------------------------
      -- GroupMngmtProtocol


  GroupMngmtProtocol ::= CHOICE {
    none      NULL,
    supported Protocol
  }

  Protocol ::= SEQUENCE {
    protocol     OBJECT IDENTIFIER,
    protocolInfo OCTET STRING


Colegrove and Harney                                          [Page 13]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006

  }

  ------------------------------------------------------------
      -- DataProtocol

  DataProtocol ::= Protocol

  ------------------------------------------------------------

  END











































Colegrove and Harney                                          [Page 14]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006

B APPENDIX B -- GSAKMPv1 Base Policy


  This appendix provides the data structures needed for when GSAKMP
  exchanges are used as the GroupMngmtProtocol for the registration,
  de-registration, and/or rekey SAs.  This GSAKMP Base Policy
  specification assumes familiarity with GSAKMP.



B.1 GSAKMPv1 Registration Policy


  When GSAKMP is used in the Group Management Protocol for
  registration, the following object identifier is used in the core
  token.


    id-GSAKMPv1RegistrationProtocol      OBJECT IDENTIFIER::= {TBD}


  The registration policy for GSAKMP provides 1) information on
  authorizations for group roles; 2) access control information for
  group members; 3) the mechanisms used in the registration process,
  and 4) information on what transport the GSAKMP registration exchange
  will use.


    GSAKMPv1RegistrationInfo ::= SEQUENCE {
      joinAuthorization JoinAuthorization,
      joinAccessControl SEQUENCE OF AccessControl,
      joinMechanisms    JoinMechanisms,
      transport         Transport
    }



B.1.1 Authorization


  joinAuthorization provides information on who is allowed to be a
      Group Controller/Key Server (GC/KS) and a sub-GC/KS. It also
      can indicate if there are limitations on who can send data in a
      group.


    JoinAuthorization ::= SEQUENCE {
      gCKS    GCKSName,
      subGCKS SEQUENCE OF GCKSName OPTIONAL,
      senders SenderAuthorization
    }


Colegrove and Harney                                          [Page 15]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006





  The authorization information is in the form of an access control
  list indicating entity name and acceptable certification authority
  information for the entity's certificate.


    GCKSName ::= SEQUENCE OF UserCAPair

    UserCAPair ::= SEQUENCE {
      groupEntity  GSAKMPID,
      cA           CertAuth
    }


  groupEntity is defined by type and value.  The types are indicated
      by integers that correspond to the GSAKMP Identification types.
      When a portion of a defined name type is filled with an "*", this
      indicates a wildcard, representing any valid choice for a field.
      This allows the specification of an authorization rule that is a
      set of related names.


    GSAKMPID ::= SEQUENCE {
      typeValue  INTEGER,
      typeData   OCTET STRING
    }


  The certificate authority is identified by the X.509 [RFC 3280] key
  identifier.


    CertAuth ::= KeyIdentifier



  Senders within a group can either be all - indicating no sender
  restrictions or can be an explicit list of those members authorized
  to send data.


    SenderAuthorization ::= CHOICE {
      all     [0] NULL,
      limited [1] EXPLICIT SEQUENCE OF UserCAPair
    }





Colegrove and Harney                                          [Page 16]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006

B.1.2 AccessControl


  joinAccessControl provides information on who is allowed to be a
      Group Member.  The access control list is implemented as a set
      of permissions that the member must satisfy and a list of name
      rules and the certificate authority that each must satisfy.
      Additionally, a list of exclusions to the list may be provided.



    AccessControl ::= SEQUENCE {
      permissions    [1] EXPLICIT SEQUENCE OF Permission OPTIONAL,
      accessRule     [2] EXPLICIT SEQUENCE OF UserCAPair,
      exclusionsRule [3] EXPLICIT SEQUENCE OF UserCAPair OPTIONAL
    }



  The permissions initially available are an abstract set of numeric
  levels that may be interpreted internal to a community.


    Permission ::= CHOICE {
      simplePermission [1] SimplePermission
    }

    SimplePermission ::= ENUMERATED {
      one(1),
      two(2),
      three(3),
      four(4),
      five(5),
      six(6),
      seven(7),
      eight(8),
      nine(9)
    }


B.1.3 JoinMechanisms


  Allowable GSAKMP mechanism choices for a particular group are
  specified in joinMechanisms.  Any set of JoinMechanism is acceptable
  from a policy perspective.


    JoinMechanisms ::=  SEQUENCE OF JoinMechanism




Colegrove and Harney                                          [Page 17]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006

  Each set of mechanisms used in the GSAKMP Registration may be
  specified either as an explicitly defined set or as a pre-defined
  security suite.



    JoinMechanism ::= CHOICE {
      alaCarte [0] Mechanisms,
      suite    [1] SecuritySuite
    }



B.1.3.1 alaCarte


  In an explicitly defined -- or alaCarte -- set, a mechanism
  is defined for the signature, the key exchange algorithm, the
  key wrapping algorithm, the type of acknowledgment data, and
  configuration data for the setting of timeouts.


    Mechanisms ::=  SEQUENCE {
      signatureDef   SigDef,
      kEAlg          KEAlg,
      keyWrap        KeyWrap,
      ackData        AckData,
      opInfo         OpInfo
    }


  The signature definition requires specification of the signature
  algorithm for message signing.  The INTEGER that defines the choice
  corresponds to the GSAKMP Signature type.


  SigDef ::= SEQUENCE {
    sigAlgorithmID  INTEGER,
    hashAlgorithmID INTEGER
  }


  The INTEGER corresponding to hashAlgorithm will map to the GSAKMP
  Nonce Hash type values.  This algorithm is used in computing the
  combined nonce.

  The key exchange algorithm requires an integer to define the GSAKMP
  key creation type and may require additional per type data.





Colegrove and Harney                                          [Page 18]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006

    KEAlg ::= SEQUENCE {
      keyExchangeAlgorithmID   INTEGER,
      keyExchangeAlgorithmData OCTET STRING OPTIONAL
    }



  The keyWrap is the algorithm that is used to wrap the group key(s)
  and the policy token (if included).  The integer corresponds to the
  GSAKMP encryption type.


    KeyWrap ::= INTEGER


  Data may potentially be returned in a GSAKMP Key Download ACK/Failure
  message.  The type of data required by a group is specified by
  AckData.  No such field is currently supported or required.


    AckData ::= CHOICE {
      none [0] NULL
    }


  OpInfo provides configuration data for the operation of GSAKMP
      registration.  timeOut indicates the elapsed amount of time
      before a sent message is considered to be misrouted or lost.  It
      is specified as the timestamp type LifeDate, previously defined
      in the core token.  terse informs a GC/KS whether the group
      should be operated in terse (TRUE) or verbose (FALSE) mode.


    OpInfo ::= SEQUENCE {
      timeOut  LifeDate,
      terse    BOOLEAN
    }



B.1.3.2 suite


  If the choice of mechanism for the join is a predefined security
  suite, then it is identified by OBJECT IDENTIFIER (OID). Other
  security suites may be defined elsewhere by specification and
  registration of an OID.


    SecuritySuite ::= OBJECT IDENTIFIER



Colegrove and Harney                                          [Page 19]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006

  The OID for security suite 1, as defined within the GSAKMPv1
  specification is



    id-securitySuiteOne  OBJECT IDENTIFIER ::= {TBD}


B.1.4 Transport


  transport indicates what protocol GSAKMP should ride over.  The
      choice of udpRTJtcpOther indicates that the GSAKMP Request to
      Join message is carried by UDP and all other group establishment
      messages are carried by TCP.


    Transport ::= CHOICE {
      tcp             [0] NULL,
      udp             [1] NULL,
      udpRTJtcpOther  [2] NULL
    }


B.2 GSAKMPv1 Registration ASN.1 Module


  GSAKMPv1RegistrationSA -- {TBD}

  DEFINITIONS IMPLICIT TAGS ::=

  BEGIN
    EXPORTS
      GCKSName;

    IMPORTS
      LifeDate
        FROM PolicyToken {TBD}

      KeyIdentifier
        FROM PKIX1Implicit88 { iso(1) identified-organization(3)
          dod(6) internet(1) security(5) mechanisms(5) pkix(7)
          id-mod(0) id-pkix1-implicit(19) };

  -- id-GSAKMPv1RegistrationProtocol  OBJECT IDENTIFIER::= {TBD}

  GSAKMPv1RegistrationInfo ::= SEQUENCE {
    joinAuthorization JoinAuthorization,
    joinAccessControl SEQUENCE OF AccessControl,
    joinMechanisms    JoinMechanisms,
    transport         Transport


Colegrove and Harney                                          [Page 20]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006

  }

  JoinAuthorization ::= SEQUENCE {
    gCKS    GCKSName,
    subGCKS SEQUENCE OF GCKSName OPTIONAL,
    senders SenderAuthorization
  }

  GCKSName ::= SEQUENCE OF UserCAPair

  UserCAPair ::= SEQUENCE {
    groupEntity GSAKMPID,
    cA          CertAuth
  }

  CertAuth ::= KeyIdentifier

  SenderAuthorization ::= CHOICE {
    all     [0] NULL,
    limited [1] EXPLICIT SEQUENCE OF UserCAPair
  }

  AccessControl ::= SEQUENCE {
    permissions    [1] EXPLICIT SEQUENCE OF Permission OPTIONAL,
    accessRule     [2] EXPLICIT SEQUENCE OF UserCAPair,
    exclusionsRule [3] EXPLICIT SEQUENCE OF UserCAPair OPTIONAL
  }

  Permission ::= CHOICE {
    simplePermission [1] SimplePermission
  }

  SimplePermission ::= ENUMERATED {
    one(1),
    two(2),
    three(3),
    four(4),
    five(5),
    six(6),
    seven(7),
    eight(8),
    nine(9)
  }

  GSAKMPID ::= SEQUENCE {
    typeValue INTEGER,
    typeData  OCTET STRING
  }

  JoinMechanisms ::=  SEQUENCE OF JoinMechanism



Colegrove and Harney                                          [Page 21]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006

  JoinMechanism ::= CHOICE {
    alaCarte [0] Mechanisms,
    suite    [1] SecuritySuite
  }

  Mechanisms ::=  SEQUENCE {
    signatureDef SigDef,
    kEAlg        KEAlg,
    keyWrap      KeyWrap,
    ackData      AckData,
    opInfo       OpInfo
  }

  SecuritySuite ::= OBJECT IDENTIFIER

  -- SECURITY SUITE ONE --
  -- id-securitySuiteOne OBJECT IDENTIFIER ::= {TBD}

  SigDef ::= SEQUENCE {
    sigAlgorithmID  INTEGER,
    hashAlgorithmID INTEGER
  }

  KEAlg ::= SEQUENCE {
    keyExchangeAlgorithmID   INTEGER,
    keyExchangeAlgorithmData OCTET STRING OPTIONAL
  }

  KeyWrap ::= INTEGER

  AckData ::= CHOICE {
    none [0] NULL
  }

  OpInfo ::= SEQUENCE {
    timeOut LifeDate,
    terse   BOOLEAN
  }

  Transport ::= CHOICE {
    tcp            [0] NULL,
    udp            [1] NULL,
    udpRTJtcpOther [2] NULL
  }

  END







Colegrove and Harney                                          [Page 22]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006

B.3 GSAKMPv1 De-Registration Policy


  GSAKMP De-Registration provides a method to notify a (S-)GC/KS that
  a member needs to leave a group.  When GSAKMP is the De-Registration
  Protocol for the Group, the following object identifier is used in
  the core token.



  id-GSAKMPv1DeRegistrationProtocol    OBJECT IDENTIFIER::= {TBD}


  The De-Registration policy provides the mechanisms needed for the
  De-Registration exchange messages, an indication of whether the
  exchange is to be done using terse (TRUE) or verbose (FALSE) mode,
  and the transport used for the GSAKMP De-registration messages.


    GSAKMPv1DeRegistrationInfo ::= SEQUENCE {
      leaveMechanisms  SEQUENCE OF LeaveMechanisms,
      terse            BOOLEAN,
      transport        Transport
    }


  The policy dictating the mechanisms needed for the De-registration
  exchange is defined by leaveMechanisms.  This field is specified as


    LeaveMechanisms ::= SEQUENCE {
      sigAlgorithm   INTEGER,
      hashAlgorithm  INTEGER,
      cA             KeyIdentifier
    }


  The INTEGER corresponding to sigAlgorithm will map to the GSAKMP
  Signature type values.  This algorithm set is to be used for message
  signing.

  The INTEGER corresponding to hashAlgorithm will map to the GSAKMP
  Nonce Hash type values.  This algorithm is used in computing the
  combined nonce.

  cA represents a trust point off of which the signer's certificate
  must certify.  It is identified by the PKIX KeyIdentifier [RFC 3280]
  type.

  transport will provide the expected transport for GSAKMP
  De-registration messages.  Initially, either UDP or TCP will be the


Colegrove and Harney                                          [Page 23]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006

  policy for a group.



    Transport ::= CHOICE {
      tcp [0] NULL,
      udp [1] NULL
    }


B.4 GSAKMPv1 De-Registration ASN.1 Module


  GSAKMPv1DeRegistrationSA -- {TBD}

  DEFINITIONS IMPLICIT TAGS ::=

  BEGIN

    IMPORTS
      KeyIdentifier
        FROM PKIX1Implicit88 { iso(1) identified-organization(3)
          dod(6) internet(1) security(5) mechanisms(5) pkix(7)
          id-mod(0) id-pkix1-implicit(19) };

  -- id-GSAKMPv1DeRegistrationProtocol OBJECT IDENTIFIER::= {TBD}

  GSAKMPv1DeRegistrationInfo ::= SEQUENCE {
    leaveMechanisms SEQUENCE OF LeaveMechanisms,
    transport       Transport
  }

  LeaveMechanisms ::= SEQUENCE {
    sigAlgorithm  INTEGER,
    hashAlgorithm INTEGER,
    cA            KeyIdentifier
  }

  Transport ::= CHOICE {
    tcp [0] NULL,
    udp [1] NULL
  }

  END


B.5 GSAKMPv1 Rekey Policy


  When GSAKMP is used as the Rekey Protocol for the Group, the
  following object identifier should be used in the core token as the


Colegrove and Harney                                          [Page 24]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006

  rekey protocol:



  id-GSAKMPv1Rekey     OBJECT IDENTIFIER::= {TBD}


  The GSAKMP Rekey Policy provides authorization information,
  mechanisms for the GSAKMP Rekey messages, indicators defining rekey
  event definitions that define when the GC/KS should send a rekey
  message, the protocol or method the rekey event will use, the rekey
  interval that will allow a member to recognize a failure in the rekey
  process, a reliability indicator that defines the method the rekey
  will use to increase the likelihood of a rekey delivery (if any), and
  finally an indication of how subordinate-GC/KSs will handle rekey.
  This policy also describes the specific Rekey policy methods "None"
  and "GSAKMP LKH REKEY".


    GSAKMPv1RekeyInfo ::= SEQUENCE {
      authorization  RekeyAuthorization,
      mechanism      RekeyMechanisms,
      rekeyEventDef  RekeyEventDef,
      rekeyMethod    RekeyMethod,
      rekeyInterval  LifeDate,
      reliability    Reliability,
      subGCKSInfo    SubGCKSInfo
    }


B.5.1 Rekey Authorization


    RekeyAuthorization ::= GCKSName


B.5.2 Rekey Mechanisms


  The policy dictating the mechanisms needed for Rekey message
  processing is defined by RekeyMechanisms.  This field is specified
  as


    RekeyMechanisms ::= SEQUENCE {
      sigAlgorithm   INTEGER,
      hashAlgorithm  INTEGER
    }





Colegrove and Harney                                          [Page 25]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006

  The INTEGER corresponding to sigAlgorithm will map to the GSAKMP
  Signature type values.  This algorithm set is to be used for message
  signing.

  The INTEGER corresponding to hashAlgorithm will map to the GSAKMP
  Nonce Hash type values.  This algorithm is used in computing the
  combined nonce.


B.5.3 Rekey Event Definition


  Rekey Event Definition provides information to the GC/KS about
  the system requirements for sending rekey messages.  This allows
  definition of the rekey event in time as well as event driven
  characteristics (a number of de-registration notifications as an
  example), or a combination of the two (e.g., after x de-registrations
  or 24 hours, whichever comes first).



    RekeyEventDef ::= CHOICE {
      none         [0]  NULL,     -- never rekey
      timeOnly     [1]  LifeDate, -- rekey every x units
      event        [2]  INTEGER,  -- rekey after x events
      timeAndEvent [3]  TimeAndEvent
    }


  The LifeDate specifies the maximum time a group should exist between
  rekeys.  This does not require clock synchronization as this is
  used with respect to a local clock.  (GC/KS clock for sending rekey
  messages or member clock for determining whether a message has been
  missed.)

  The INTEGER corresponding to the event is an indicator of the number
  of events a group should sustain before a rekey message is sent.
  This defines the events between rekeys.  An example of a relevant
  event is de-registration notifications.

  The TimeAndEvent is defined as a couple of the LifeDate and Integer
  policies.


    TimeAndEvent ::= SEQUENCE {
      time   LifeDate, -- rekey after x units of time OR
      event  INTEGER   -- x events occur
    }





Colegrove and Harney                                          [Page 26]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006

B.5.4 Rekey Methods


  Rekey Method defines the policy of how the rekey is to be
  accomplished.  This field is specified as



    RekeyMethod ::= SEQUENCE {
      rekeyMethodType  OBJECT IDENTIFIER,
      rekeyMethodInfo  OCTET STRING
    }


  The rekeyMethodType will define the rekey method to be used by the
  group.

  The rekeyMethodInfo will supply the GMs with the information they
  need to operate in the correct rekey mode.


B.5.4.1 Rekey Method NONE


  The group defined to work without a rekey protocols supporting
  it is supported by the rekeyMethodType NONE. There is no
  RekeyMethodNoneInfo associated with this option.


    id-rekeyNone OBJECT IDENTIFIER ::= {TBD}

    RekeyMethodNoneInfo ::= NULL


B.5.4.2 Rekey Method GSAKMP LKH


  The GSAKMP protocol specification defined an interpretation of the
  Logical Key Hierarchy (LKH) protocol as a rekey method.  This method
  is supported by the following values.


    id-rekeyMethodGSAKMPLKH OBJECT IDENTIFIER ::= {TBD}

    RekeyMethodGSAKMPLKHInfo ::= INTEGER


  The GSAKMP LKH method requires a gsakmp type value for identifying
  the cryptographic algorithm used to wrap the keys.  This value maps
  to the GSAKMP encryption type.



Colegrove and Harney                                          [Page 27]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006

B.5.5 Rekey Interval


  Rekey interval defines the maximum delay the GM should see
  between valid rekeys.  This provides a means to ensure the GM is
  synchronized, from a key management perspective, with the rest of the
  group.  It is defined as a time/date stamp.


B.5.6 Rekey Reliability


  The Rekey message in the GSAKMP protocol is a single push message.
  There are reliability concerns with such non-acknowledged messages
  (i.e.  message exchange).  The Reliability policy defines the
  mechanism used to deal with these concerns.



    Reliability ::= SEQUENCE {
      reliabilityMechanism   OBJECT IDENTIFIER,
      reliabilityMechContent OCTET STRING
    }


  The reliability mechanism is defined by an OBJECT IDENTIFIER and
  the information needed to operate that mechanism is defined as
  reliabilityMechContent and is an OCTET STRING. (as before)


B.5.6.1 Rekey Reliability Mechanism None


  In networks with adequate reliability it may not be necessary to use
  a mechanism to improve reliability of the Rekey Message.  For these
  networks the ReliabilityMechanism NONE is appropriate.


    id-reliabilityNone OBJECT IDENTIFIER ::= {TBD}

    ReliabilityContentNone ::= NULL


B.5.6.2 Rekey Reliability Mechanism Resend


  In networks with unknown or questionable reliability it may be
  necessary to use a mechanism to improve reliability of the Rekey
  Message.  For these networks the ReliabilityMechanism RESEND is
  potentially appropriate.  This mechanism has the GC/KS repeatedly
  sending out the same message.


Colegrove and Harney                                          [Page 28]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006

    id-reliabilityResend OBJECT IDENTIFIER ::= {TBD}

    ReliabilityResendInfo ::= INTEGER



  The INTEGER value in the ReliabilityResendInfo indicates the number
  of times the message should be resent.


B.5.6.3 Rekey Reliability Mechanism Post


  Another reliability mechanism is to post the rekey message on
  some service that will make it generally available.  This is the
  reliabilityPost method.


    id-reliabilityPost OBJECT IDENTIFIER ::= {TBD}

    ReliabilityContentPost ::= IA5String


  The IA5String associated with ReliabilityPost is the identifier of
  the posting site and rekey message.


B.5.7 Distributed Operation Policy


  The policy dictating the relationships between GC/KS and S-GC/KS for
  distributed operations is defined as SubGCKSInfo.  It is defined as
  a couple of a subGCKSScheme and some information relating to that
  Scheme in sGCKSContent.


    SubGCKSInfo ::= SEQUENCE {
      subGCKSScheme OBJECT IDENTIFIER,
      sGCKSContent  OCTET STRING
    }


B.5.7.1 No Distributed Operation


  If the group is not to use S-GC/KS then that Scheme would be
  SGCKSSchemeNone.






Colegrove and Harney                                          [Page 29]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006

    id-subGCKSSchemeNone OBJECT IDENTIFIER ::= {TBD}

    SGCKSNoneContent ::= NULL



B.5.7.2 Autonomous Distributed Mode


  If the group is to use S-GC/KS as defined in the GSAKMP specification
  as Autonomous mode, then that scheme would be SGCKSAutonomous.


    id-subGCKSSchemeAutonomous    OBJECT IDENTIFIER ::= {TBD}

    SGCKSAutonomous ::= SEQUENCE {
      authSubs  GCKSName,
      domain    OCTET STRING OPTIONAL
    }


  The policy information needed for autonomous mode is a list of
  authorized S-GC/KSs and and restrictions on who they may serve.
  The domain field, representing these restrictions is NULL for this
  version.


B.6 GSAKMPv1 Rekey Policy ASN.1 Module


  GSAKMPv1RekeySA -- {TBD}

  DEFINITIONS IMPLICIT TAGS ::=

  BEGIN

    IMPORTS
      GCKSName
        FROM GSAKMPv1RegistrationSA  {TBD}
      LifeDate
        FROM PolicyToken  {TBD};

  -- id-GSAKMPv1Rekey OBJECT IDENTIFIER::= {TBD}

  GSAKMPv1RekeyInfo ::= SEQUENCE {
    authorization RekeyAuthorization,
    mechanism     RekeyMechanisms,
    rekeyEventDef RekeyEventDef, -- tells the GCKS when to rekey
    rekeyMethod   RekeyMethod,
    rekeyInterval LifeDate,      -- member knows when to rejoin
    reliability   Reliability,   -- what mech will be used to


Colegrove and Harney                                          [Page 30]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006

                                 --   increase the likelihood
                                 --   of rekey delivery
    subGCKSInfo   SubGCKSInfo    -- what subordinate gcks needs
  }

  RekeyAuthorization ::= GCKSName

  RekeyMechanisms ::= SEQUENCE {
    sigAlgorithm  INTEGER,
    hashAlgorithm INTEGER
  }

  RekeyEventDef ::= CHOICE {
    none         [0] NULL,              -- never rekey
    timeOnly     [1] EXPLICIT LifeDate, -- rekey every x units
    event        [2] INTEGER,           -- rekey after x events
    timeAndEvent [3] TimeAndEvent
  }

  TimeAndEvent ::= SEQUENCE {
    time  LifeDate, -- rekey after x units of time OR
    event INTEGER   -- x events occur
  }

  RekeyMethod ::= SEQUENCE {
    rekeyMethodType OBJECT IDENTIFIER,
    rekeyMethodInfo OCTET STRING
  }

  -- REKEY METHOD NONE --

  -- id-rekeyNone OBJECT IDENTIFIER ::= {TBD}

  RekeyMethodNoneInfo ::= NULL

  -- REKEY METHOD GSAKMP LKH --

  -- id-rekeyMethodGSAKMPLKH OBJECT IDENTIFIER ::= {TBD}

  RekeyMethodGSAKMPLKHInfo ::= INTEGER -- gsakmp type value for
                                       --   wrapping mechanism

  Reliability ::= SEQUENCE {
    reliabilityMechanism   OBJECT IDENTIFIER,
    reliabilityMechContent OCTET STRING
  }

  -- RELIABILITY MECHANISM NONE --

  -- id-reliabilityNone OBJECT IDENTIFIER ::= {TBD}



Colegrove and Harney                                          [Page 31]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006

  ReliabilityContentNone ::= NULL

  -- RELIABILITY MECHANISM RESEND --

  -- id-reliabilityResend OBJECT IDENTIFIER ::= {TBD}

  ReliabilityResendInfo ::= INTEGER -- # of times rekey message should
                                    --   be resent

  -- RELIABILITY MECHANISM POST --
  -- id-reliabilityPost OBJECT IDENTIFIER ::= {TBD}

  ReliabilityContentPost ::= IA5String

  SubGCKSInfo ::= SEQUENCE {
    subGCKSScheme OBJECT IDENTIFIER,
    sGCKSContent  OCTET STRING
  }

  -- id-subGCKSSchemeNone OBJECT IDENTIFIER ::= {TBD}

  SGCKSNoneContent ::= NULL

  -- id-subGCKSSchemeAutonomous OBJECT IDENTIFIER ::= {TBD}

  SGCKSAutonomous ::= SEQUENCE {
    authSubs GCKSName,
    domain   OCTET STRING OPTIONAL
  }

  END






















Colegrove and Harney                                          [Page 32]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006

C APPENDIX C -- Data SA Policy


  The Data SA provides the data structures needed for the protection
  of the data exchanged between group members.  This appendix defines
  the data structures needed for a simple, generic security application
  making use of fixed security mechanisms.  Such a Data SA requires
  only that keys delivered by the registration and rekey protocols be
  mapped to the service using them.



C.1 Generic Data Policy


  The Generic Data Policy has the following identifier:


    id-genericDataSA OBJECT IDENTIFIER :: = TBD


  If an authentication mechanism is used within the security
  application, the key identifier (kMKeyID) used in the key management
  protocol is given, as well as an optional key expiration date.
  Likewise, if an encryption mechanism is used within the security
  application, the encryption key identifier is given, as well as an
  optional key expiration date (keyExpirationDate).


    GenericDataSAInfo ::= SEQUENCE {
      authentication [0] EXPLICIT KeyInfo OPTIONAL,
      encryption     [1] EXPLICIT KeyInfo OPTIONAL
    }

    KeyInfo ::= SEQUENCE{
      kMKeyID           OCTET STRING,
      keyExpirationDate LifeDate OPTIONAL
    }















Colegrove and Harney                                          [Page 33]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006

C.2 Generic Data Policy ASN.1 Module


  GenericDataSA -- {TBD}

  DEFINITIONS IMPLICIT TAGS ::=

  BEGIN

  -- DATA APPLICATION:  Generic
  -- This token specification is for data applications with
  -- fixed security mechanisms.  Such data applications only
  -- need a mapping of management protocol key identification
  -- tags to security service.

    IMPORTS
      LifeDate
        FROM PolicyToken {TBD}

      KeyIdentifier
        FROM PKIX1Implicit88 { iso(1) identified-organization(3)
          dod(6) internet(1) security(5) mechanisms(5) pkix(7)
          id-mod(0) id-pkix1-implicit(19) };

  -- id-genericDataSA        OBJECT IDENTIFIER ::= {TBD}

  GenericDataSAInfo ::= SEQUENCE {
    authentication [0] EXPLICIT KeyInfo OPTIONAL,
    encryption     [1] EXPLICIT KeyInfo OPTIONAL
  }

  KeyInfo ::= SEQUENCE{
    kMKeyID           OCTET STRING,
    keyExpirationDate LifeDate OPTIONAL
  }

  END



D APPENDIX D -- Change History (To Be Removed from RFC)


D.1 Changes from Group Policy Token v-00 to v-01, December 2004


   -  Editorial/Grammatical changes throughout the document.

   -  Core Policy Token ASN.1 Module Appendix rewritten.

   -  GSAKMPv1 Registration ASN.1 Module Appendix rewritten.


Colegrove and Harney                                          [Page 34]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006

   -  GSAKMPv1 De-Registration ASN.1 Module Appendix rewritten.

   -  GSAKMPv1 Rekey Policy ASN.1 Module Appendix rewritten.

   -  RFC 3711 Policy Appendix was rewritten.



D.2 Changes from Group Policy Token v-01 to v-02, March 2005


   -  RFC 3711 policy removed.

   -  Generic Data SA provided.


D.3 Changes from Group Policy Token v-02 to v-03, July 2005


   -  Consistency corrections between text and ASN.1 modules.

   -  Explicit tagging in sequences of sequences to avoid encoding
      ambiguities.


D.4 Changes from Group Policy Token v-03 to v-04, September 2005


   -  Authorization field for group senders.

   -  Editorial corrections.

   -  Renamed to "Group Security Policy Token".



D.5 Changes from Group Policy Token v-04 to v-05, December 2005


   -  Removed constraints on CMS signing-time attribute.

   -  Removed unnecessary explicit tags in CHOICE constructs of the
      core token.


D.6 Changes from Group Policy Token v-05 to v-06, January 2006


   -  Added explanation paragraphs to section The Policy Token.

   -  Added tokenDefVersion field to TokenID structure.


Colegrove and Harney                                          [Page 35]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006

   -  Added updating/extension rules to the IANA Considerations
      section.



















































Colegrove and Harney                                          [Page 36]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006

Authors' Addresses

  Andrea Colegrove
  SPARTA, Inc.
  7075 Samuel Morse Drive
  Columbia, MD 21046
  (410) 872-1515 ext 232
  FAX (410) 872-8079
  acc@sparta.com


  Hugh Harney
  SPARTA, Inc.
  7075 Samuel Morse Drive
  Columbia, MD 21046
  (410) 872-1515 ext 203
  FAX (410) 872-8079
  hh@sparta.com


Full Copyright Statement

  Copyright (C) The Internet Society (2006).  This document is subject
  to the rights, licenses and restrictions contained in BCP 78, and
  except as set forth therein, the authors retain all their rights.

  This document and the information contained herein are provided
  on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
  REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
  INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

IPR Considerations

  By submitting this Internet-Draft, each author represents that any
  applicable patent or other IPR claims of which he or she is aware
  have been or will be disclosed, and any of which he or she becomes
  aware will be disclosed, in accordance with Section 6 of BCP 79.

  The IETF takes no position regarding the validity or scope of any
  Intellectual Property Rights or other rights that might be claimed
  to pertain to the implementation or use of the technology described
  in this document or the extent to which any license under such rights
  might or might not be available; nor does it represent that it has
  made any independent effort to identify any such rights.  Information
  on the procedures with respect to rights in RFC documents can be
  found in BCP 78 and BCP 79.




Colegrove and Harney                                          [Page 37]

INTERNET-DRAFT         Group Security Policy Token v1      January 2006

  Copies of IPR disclosures made to the IETF Secretariat and any
  assurances of licenses to be made available, or the result of an
  attempt made to obtain a general license or permission for the
  use of such proprietary rights by implementers or users of this
  specification can be obtained from the IETF on-line IPR repository
  at http://www.ietf.org/ipr.

  The IETF invites any interested party to bring to its attention any
  copyrights, patents or patent applications, or other proprietary
  rights that may cover technology that may be required to implement
  this standard.  Please address the information to the IETF at ietf-
  ipr@ietf.org.

Document expiration:  July 23, 2006







































Colegrove and Harney                                          [Page 38]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/