Internet Engineering Task Force
INTERNET-DRAFT                                          A Colegrove (SPARTA)
                                                           H Harney (SPARTA)
draft-ietf-msec-policy-token-sec-02.txt                         SPARTA, Inc.
Expires:  September 7, 2005                                       March 2005


              Group Policy Token V1 with Application to GSAKMP




                            Status of this memo



By submitting this Internet-Draft, the authors certify that any applicable
patent or other IPR claims of which I am (we are) aware have been disclosed,
or will be disclosed, and any of which I (we) become aware will be
disclosed, in accordance with RFC 3668 (BCP 79).

By submitting this Internet-Draft, the authors accept the provisions of
Section 3 of RFC 3667 (BCP 78).

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/ietf/1id-abstracts.txt

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


                                  Abstract


     The Policy Token is a structure used to specify the security
    policy and configurable parameters for a cryptographic group, such
    as a secure multicast group.  This document specifies the structure
    of such a token in order to securely bind system-level security to
    protocols supporting the management of cryptographic groups.


INTERNET-DRAFT  Group Policy Token V1 with Application to GSAKMP  March 2005

  Copyright Notice Copyright (c) The Internet Society (2005).  All Rights
                                 Reserved.



















































Colegrove and Harney    draft-ietf-msec-policy-token-sec-02.txt     [Page 2]


INTERNET-DRAFT  Group Policy Token V1 with Application to GSAKMP  March 2005

Contents

1 Introduction                                                             5

2 Token Creation and Receipt                                               6
3 The Policy Token                                                         6
  3.1 tokenInfo   . . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
  3.2 registration  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
  3.3 rekey  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
  3.4 data  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  9

4 Security Considerations                                                  9
5 IANA Considerations                                                      9

6 References                                                              10
  6.1 Normative References  . . . . . . . . . . . . . . . . . . . . . . . 10
  6.2 Non-Normative References  . . . . . . . . . . . . . . . . . . . . . 10

7 Acknowledgements                                                        11
A APPENDIX A -- Core Policy Token ASN.1 Module                            12

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

D APPENDIX D -- Change History (To Be Removed from RFC)                   32
  D.1 Changes from Group Policy Token v-00 to v-01, December 2004 . . . . 32

Colegrove and Harney    draft-ietf-msec-policy-token-sec-02.txt     [Page 3]


INTERNET-DRAFT  Group Policy Token V1 with Application to GSAKMP  March 2005

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

Authors Addresses                                                         33
Full Copyright Statement                                                  33

















































Colegrove and Harney    draft-ietf-msec-policy-token-sec-02.txt     [Page 4]


INTERNET-DRAFT  Group Policy Token V1 with Application to GSAKMP  March 2005

1 Introduction


The Multicast Group Security Architecture [HW05] 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 member is submitting to the group.

The policy token is specified in ASN.1 and is to be DER 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    draft-ietf-msec-policy-token-sec-02.txt     [Page 5]


INTERNET-DRAFT  Group Policy Token V1 with Application to GSAKMP  March 2005

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-msec-token    OBJECT IDENTIFIER ::= {TBD}


The CMS sid value of the SignerInfo 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
and MUST be specified as a GeneralizedTime value.

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 succeeds in accordance with RFC 3369

 -  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    draft-ietf-msec-policy-token-sec-02.txt     [Page 6]


INTERNET-DRAFT  Group Policy Token V1 with Application to GSAKMP  March 2005

  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 mechansims
    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 SHOULD 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 SHOULD 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.


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


3.1 tokenInfo


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


  TokenID ::= SEQUENCE {
    groupName OCTET STRING,
    edition   INTEGER OPTIONAL
  }



Colegrove and Harney    draft-ietf-msec-policy-token-sec-02.txt     [Page 7]


INTERNET-DRAFT  Group Policy Token V1 with Application to GSAKMP  March 2005

groupName is the identifier of the group

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.



3.2 registration


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 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 layer SA.


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


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


  GroupMngmtProtocol ::= CHOICE {
    none      [0]     NULL,
    supported [1]     Protocol
  }

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


For example, register might be specified as the GSAKMP [HMC] 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


The Rekey SA is defined in the MSEC Architecture.  During Rekey, the
membership of the group can be modified as well as refreshing the group
traffic protection keys and updating the Policy Token.

Colegrove and Harney    draft-ietf-msec-policy-token-sec-02.txt     [Page 8]


INTERNET-DRAFT  Group Policy Token V1 with Application to GSAKMP  March 2005

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



3.4 data


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
multicast key, ranging from simple security applications needing key only
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


The 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-msec-token OBJECT IDENTIFIER ::= TBD

 -  id-securitySuiteOne OBJECT IDENTIFIER ::= TBD

 -  id-GSAKMPv1RegistrationProtocol OBJECT IDENTIFIER::= TBD


Colegrove and Harney    draft-ietf-msec-policy-token-sec-02.txt     [Page 9]


INTERNET-DRAFT  Group Policy Token V1 with Application to GSAKMP  March 2005

 -  id-GSAKMPv1DeRegistrationProtocol OBJECT IDENTIFIER::= TBD

 -  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



6 References


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


6.1 Normative References


[HMC] H. Harney, U. Meth, and A. Colegrove, "GSAKMP",
draft-ietf-msec-gsakmp-sec-08.txt, work in progress, March 2005.

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

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


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)", March 2004.

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


Colegrove and Harney    draft-ietf-msec-policy-token-sec-02.txt    [Page 10]


INTERNET-DRAFT  Group Policy Token V1 with Application to GSAKMP  March 2005

Architecture", 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, Work in progress.



7 Acknowledgements


The following individuals deserve recognition and thanks for their
contributions which have greatly improved this specification:  Uri Meth, Rod
Fleischer, Peter Lough, Thomas Hardjono, Patrick McDaniel, and Pete Dinsmore
for their work on earlier versions of policy tokens; and George Gross for
the impetus to have a well-specified, extensible policy token.

































Colegrove and Harney    draft-ietf-msec-policy-token-sec-02.txt    [Page 11]


INTERNET-DRAFT  Group Policy Token V1 with Application to GSAKMP  March 2005

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 {
  groupName OCTET STRING,
  edition   INTEGER OPTIONAL
}

LifeDate ::= CHOICE {
  gt       [0] GeneralizedTime,
  utc      [1] UTCTime,
  interval [2] INTEGER
}

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

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

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

GroupMngmtProtocol ::= CHOICE {
  none      [0] NULL,
  supported [1] Protocol
}

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



Colegrove and Harney    draft-ietf-msec-policy-token-sec-02.txt    [Page 12]


INTERNET-DRAFT  Group Policy Token V1 with Application to GSAKMP  March 2005

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

DataProtocol ::= Protocol

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

END













































Colegrove and Harney    draft-ietf-msec-policy-token-sec-02.txt    [Page 13]


INTERNET-DRAFT  Group Policy Token V1 with Application to GSAKMP  March 2005

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.


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




The authorization information is in the form of an access control list
indicating entity name and acceptable certification authority information

Colegrove and Harney    draft-ietf-msec-policy-token-sec-02.txt    [Page 14]


INTERNET-DRAFT  Group Policy Token V1 with Application to GSAKMP  March 2005

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 key identifier.


  CertAuth ::= KeyIdentifier


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 is provided.



  AccessControl ::= SEQUENCE {
    permissions    SEQUENCE OF Permission OPTIONAL,
    accessRule     SEQUENCE OF UserCAPair,
    exclusionsRule SEQUENCE OF UserCAPair OPTIONAL
  }



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

Colegrove and Harney    draft-ietf-msec-policy-token-sec-02.txt    [Page 15]


INTERNET-DRAFT  Group Policy Token V1 with Application to GSAKMP  March 2005

  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


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
  }



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 acknowledgement data, and configuration data for the setting of
timeouts.









Colegrove and Harney    draft-ietf-msec-policy-token-sec-02.txt    [Page 16]


INTERNET-DRAFT  Group Policy Token V1 with Application to GSAKMP  March 2005

  Mechanisms ::=  SEQUENCE {
    signatureDef   SigDef,
    hashAlgorithm  INTEGER,
    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 ::= INTEGER


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

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


  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.

Colegrove and Harney    draft-ietf-msec-policy-token-sec-02.txt    [Page 17]


INTERNET-DRAFT  Group Policy Token V1 with Application to GSAKMP  March 2005

    timeout indicates the elapsed amount of time before a sent message is
    considered to be misrouted or lost.  It is specified as a time.  terse
    informs a GC/KS whether the group should be operated in terse (TRUE) or
    verbose (FALSE) mode.



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


  LifeDate ::= CHOICE {
    gt  [0] GeneralizedTime,
    utc [1] UTCTime
  }


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


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
  }




Colegrove and Harney    draft-ietf-msec-policy-token-sec-02.txt    [Page 18]


INTERNET-DRAFT  Group Policy Token V1 with Application to GSAKMP  March 2005

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
}

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

GCKSName ::= SEQUENCE OF UserCAPair

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

CertAuth ::= KeyIdentifier

AccessControl ::= SEQUENCE {
  permissions    SEQUENCE OF Permission OPTIONAL,
  accessRule     SEQUENCE OF UserCAPair,
  exclusionsRule SEQUENCE OF UserCAPair OPTIONAL
}

Permission ::= CHOICE {
  simplePermission [1] SimplePermission


Colegrove and Harney    draft-ietf-msec-policy-token-sec-02.txt    [Page 19]


INTERNET-DRAFT  Group Policy Token V1 with Application to GSAKMP  March 2005

}

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

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



Colegrove and Harney    draft-ietf-msec-policy-token-sec-02.txt    [Page 20]


INTERNET-DRAFT  Group Policy Token V1 with Application to GSAKMP  March 2005

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

OpInfo ::= SEQUENCE {
  timeOut LifeDate
}

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

END



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  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
  }

Colegrove and Harney    draft-ietf-msec-policy-token-sec-02.txt    [Page 21]


INTERNET-DRAFT  Group Policy Token V1 with Application to GSAKMP  March 2005

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 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 LeaveMechanisms,
  transport       Transport
}

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

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

Colegrove and Harney    draft-ietf-msec-policy-token-sec-02.txt    [Page 22]


INTERNET-DRAFT  Group Policy Token V1 with Application to GSAKMP  March 2005


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 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 likelyhood 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, -- tells the GCKS when to rekey
    rekeyMethod    RekeyMethod,
    rekeyInterval  LifeDate, -- member knows when to rejoin
    reliability    Reliability, -- what mech will be used to increase
                                --   the likelihood of rekey delivery
    subGCKSInfo    SubGCKSInfo  -- what subordinate gcks needs
  }


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



Colegrove and Harney    draft-ietf-msec-policy-token-sec-02.txt    [Page 23]


INTERNET-DRAFT  Group Policy Token V1 with Application to GSAKMP  March 2005

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



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, which ever 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.

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 notificaitons.

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    draft-ietf-msec-policy-token-sec-02.txt    [Page 24]


INTERNET-DRAFT  Group Policy Token V1 with Application to GSAKMP  March 2005

B.5.4 Rekey Methods


The policy dictating the rekey method supported by the Rekey message is
defined by RekeyMethod.  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    draft-ietf-msec-policy-token-sec-02.txt    [Page 25]


INTERNET-DRAFT  Group Policy Token V1 with Application to GSAKMP  March 2005

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 one sided exchange of data.
There are reliability concerns with one sided exchanges.  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    draft-ietf-msec-policy-token-sec-02.txt    [Page 26]


INTERNET-DRAFT  Group Policy Token V1 with Application to GSAKMP  March 2005

  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 mechanims 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.


  id-subGCKSSchemeNone OBJECT IDENTIFIER ::= {TBD}

  SGCKSNoneContent ::= NULL


Colegrove and Harney    draft-ietf-msec-policy-token-sec-02.txt    [Page 27]


INTERNET-DRAFT  Group Policy Token V1 with Application to GSAKMP  March 2005

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 increase
                               --  the likelyhood of rekey delivery
  subGCKSInfo   SubGCKSInfo    -- what subordinate gcks needs
}

RekeyAuthorization ::= GCKSName


Colegrove and Harney    draft-ietf-msec-policy-token-sec-02.txt    [Page 28]


INTERNET-DRAFT  Group Policy Token V1 with Application to GSAKMP  March 2005

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

RekeyEventDef ::= CHOICE {
  none         [0] NULL,     -- never rekey
  timeOnly     [1] 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}

ReliabilityContentNone ::= NULL

-- RELIABILITY MECHANISM RESEND --

id-reliabilityResend OBJECT IDENTIFIER ::= {TBD}

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


Colegrove and Harney    draft-ietf-msec-policy-token-sec-02.txt    [Page 29]


INTERNET-DRAFT  Group Policy Token V1 with Application to GSAKMP  March 2005


-- 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 ::= NULL

END



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 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.


  GenericDataSAInfo ::= SEQUENCE {
    authentication [0] KeyInfo OPTIONAL,

Colegrove and Harney    draft-ietf-msec-policy-token-sec-02.txt    [Page 30]


INTERNET-DRAFT  Group Policy Token V1 with Application to GSAKMP  March 2005

    encryption     [1] KeyInfo OPTIONAL
  }

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



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] KeyInfo OPTIONAL,
  encryption     [1] KeyInfo OPTIONAL
}

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

END






Colegrove and Harney    draft-ietf-msec-policy-token-sec-02.txt    [Page 31]


INTERNET-DRAFT  Group Policy Token V1 with Application to GSAKMP  March 2005

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.

 -  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.



























Colegrove and Harney    draft-ietf-msec-policy-token-sec-02.txt    [Page 32]


INTERNET-DRAFT  Group Policy Token V1 with Application to GSAKMP  March 2005

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 (2005).  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.

Document expiration:  September 7, 2005


















Colegrove and Harney    draft-ietf-msec-policy-token-sec-02.txt    [Page 33]