RFC 4534

Group Security Policy Token v1

📅 published June 2006, from ietf

RFC 4534: Group Security Policy Token v1 🎀

okay bestie, this one is the Group Security Policy Token v1 spec 💅 It's an Internet standards track protocol doc, so implementers are expected to follow it closely. The title block says it's from the Network Working Group and is RFC 4534. The authors are A. Colegrove and H. Harney from SPARTA, Inc., and it's dated June 2006 🦋. The title block doesn't list anything it obsoletes or updates, so it stands on its own ✨.

Status of This Memo ✨

This document is an Internet standards track protocol for the Internet community. It's asking for discussion and suggestions for improvements 🫶. If you want to know where this protocol currently sits in standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈.

Copyright (C) The Internet Society (2006).

Abstract 🧚

okay so the Group Security Policy Token is a structure that describes the security policy and the configurable settings for a cryptographic group, like a secure multicast group 💜. Here's why it matters: a group's security is the combination of lots of security services, mechanisms, and attributes spread across the whole communications setup. So you need a token that can be authenticated and that shows which features have to be supported across the whole system, otherwise your security won't be consistent 😭. This document defines what that token looks like 🎀.

Table of Contents 📖

1. Introduction ....................................................3
2. Token Creation and Receipt ......................................4
3. The Policy Token ................................................5
   3.1. Token Identifiers ..........................................6
   3.2. Registration Policy ........................................6
   3.3. Rekey Policy ...............................................7
   3.4. Group Data Policy ..........................................8
4. Security Considerations .........................................8
5. IANA Considerations .............................................8
6. References.......................................................9
   6.1. Normative References .......................................9
   6.2. Informative References ....................................10
7. Acknowledgements ...............................................10
Appendix A. Core Policy Token ASN.1 Module ........................11
Appendix B. GSAKMPv1 Base Policy ..................................13
   B.1. GSAKMPv1 Registration Policy ..............................13
        B.1.1. Authorization .......................................13
        B.1.2. AccessControl .......................................14
        B.1.3. JoinMechanisms ......................................15
               B.1.3.1. alaCarte ...................................15
               B.1.3.2. suite ......................................17
        B.1.4. Transport ...........................................17
   B.2. GSAKMPv1 Registration ASN.1 Module ........................17
   B.3. GSAKMPv1 De-Registration Policy ...........................20
   B.4. GSAKMPv1 De-Registration ASN.1 Module .....................21
   B.5. GSAKMPv1 Rekey Policy .....................................22
        B.5.1. Rekey Authorization ................................22
        B.5.2. Rekey Mechanisms ...................................23
        B.5.3. Rekey Event Definition .............................23
        B.5.4. Rekey Methods ......................................24
               B.5.4.1 Rekey Method NONE ..........................24
               B.5.4.2 Rekey Method GSAKMP LKH ....................24
        B.5.5 Rekey Interval ......................................25
        B.5.6 Rekey Reliability ...................................25
               B.5.6.1 Rekey Reliability Mechanism None ............25
               B.5.6.2 Rekey Reliability Mechanism Resend ..........25
               B.5.6.3 Rekey Reliability Mechanism Post ............26
        B.5.7 Distributed Operation Policy ........................26
               B.5.7.1 No Distributed Operation ....................26
               B.5.7.2 Autonomous Distributed Mode .................26
   B.6. GSAKMPv1 Rekey Policy ASN.1 Module ........................27
Appendix C. Data SA Policy ........................................30
   C.1. Generic Data Policy .......................................30
   C.2. Generic Data Policy ASN.1 Module ..........................30

1. Introduction 🌷

okay so the Multicast Group Security Architecture [RFC3740] is the big-picture framework for secure group communications 🦋. This policy token is built on top of that architecture, and it defines the security parameters that actually get enforced for a Group Secure Association 💅.

The token is a verifiable data construct, and the Group Owner signs it. The Group Owner is the entity that's authorized to create the security policy 👑. The group controllers use the token to make sure the mechanisms securing the group are correct, and to enforce the access control rules for members who want to join 🔥. Group members can contribute data to the group or read data from it, and they use the token to confirm the group is owned by a trusted authority 🫶. Members may also want to check that the access control rules are strong enough to protect the data they're sending into the group 🙈.

The token is written in ASN.1 [X.208] and encoded with DER [X.660] 🧚. Using ASN.1 makes it easy to import group definitions that span different applications and environments ✨. It also lets the token have branches that any multicast security protocol can use, so a group can use this token to set up several protocols at once 🌈.

The spec gives the token a core level of detail, which keeps it extensible and flexible for supporting different mechanisms 💜. This is done with the following abstract construct:

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

This construct lets group mechanisms from other documents work with the policy token 🎀.

The token's structure follows the MSEC Architecture layers for a Group Security Association 🍓. Each architectural layer gets identified and given its own branch in the "Core" token ✨. That means future protocol specs can do their thing at each layer without changing the "Core" policy token, and the "Core" token can serve as the single reference point for defining secure groups with any mix of protocols across any number of environments 😭🦋.

2. Token Creation and Receipt 💖

Whenever a group gets created, or its policy gets updated, the Group Owner makes a new policy token 🌸.

To make sure the specified policy is authentic, the Token MUST be signed by the Group Owner 🔥. The signed token MUST follow the Cryptographic Message Syntax (CMS) [RFC3852] SignedData type 💅.

The content of the SignedData is the token itself 🧚. It's identified with this ContentType object identifier:

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

The CMS sid value in the SignerInfo tells you which public key you need to validate the signature. That sid MUST be the Group Owner's 👑.

The signedAttrs field MUST be present 🌈. On top of the minimally required fields of signedAttrs, the signing-time attribute MUST be present too ⏰.

When a recipient gets a policy token, they MUST check all of the following 🔍:

  • the Group Owner, identified by the sid in the SignerInfo, is the entity they expected 💜
  • the signing-time value is more recent than the signing-time value from a policy token they got before for that group, or this is the first token they've seen for that group 🎀
  • the signature processing validates successfully under RFC 3852 ✨
  • the security and communication mechanisms listed (or at least one mechanism from each choice) are supported and comply with the recipient's local policy 🫶

3. The Policy Token 🦋

The policy token is laid out like this:

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

tokenInfo gives you info about this particular instance of the Policy Token (PT) 🌟.

registration lists the acceptable registration and de-registration policies and mechanisms that can manage members joining and leaving the group on their own 🚪. A NULL sequence means the group doesn't support registration or de-registration of members 🙈. A member MUST be able to support at least one set of Registration mechanisms to join the group 🔑. If several mechanisms are listed, a member MAY use any of them 🌸. The list is ordered by Group Owner preference, and a member MUST choose the highest listed mechanism that their local policy supports 👑.

rekey lists the rekey protocols used to manage the group 🔄. The member MUST be able to accept one of the listed rekey message types 💅. The list is ordered by Group Owner preference, and a member MUST choose the highest listed mechanism their local policy supports 🌈.

data lists the applications used for communication between group members 💬. When there are multiple applications, the order of the list tells you the order of encapsulation for the data 🧁. A member MUST be able to support all the listed applications, and if any application offers a choice of mechanisms, the member MUST support at least one of them 🫶.

For the registration, rekey, and data fields, implementations that run into unknown protocol identifiers MUST handle them gracefully by giving indicators that an unknown protocol is in the list of permissible protocols 🔍. If the unknown protocol is the only allowable one in the sequence, the implementation can't support that field, and the member can't join the group 😭. Whether a join is allowed when an unknown protocol sits alongside known, allowable protocols is up to local policy 🎀.

Protocols beyond registration, rekey, and data SHOULD NOT be added to later versions of this Token unless the MSEC architecture changes 🙅‍♀️. Each data field of the PT gets its own detailed section below ✨.

3.1. Token Identifiers ✨

okay so tokenInfo is how a policy token says "this is exactly which version of me, for this specific group" 🎀 It's defined like this:

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

tokenDefVersion is the version of the Group Policy Token Specification. This spec (v1) is written as 1. If the structure of the Group Security Policy Token ever changes, this field needs an update 🧚

groupName is the identifier of the group, and it MUST be unique relative to the Group Owner. bestie, that's non-negotiable 💅

edition is an optional INTEGER that tracks the sequence number of the PT. When edition is present, group entities MUST accept a PT only when its value is greater than the last value they saw in a valid PT for that group. so no going backwards on editions, periodt 🙅‍♀️

There's also a type called LifeDate, which gives us standard ways to show timestamps and intervals inside the Tokens ⏰

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

3.2. Registration Policy 🌸

The registration security association (SA) is defined in the MSEC Architecture. During registration, a prospective group member and the group controller work together so the member gets the keys and info it needs to join the group and take part in the group Data SA 🔑

The de-registration piece is how a current group member tells the Group Controller Key Server (GC/KS) that it's leaving the Data SA. bye bye, see ya 👋

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

The protocols 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 could be specified as the Group Secure Association Key Management Protocol (GSAKMP) [RFC4535] registration protocol. The OBJECT IDENTIFIER TBS would then 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 a Rekey of a group, a few things can potentially change:

  • refresh/change group protection keys,
  • update the policy token,
  • change the group membership.

So during Rekey, the group's membership can be modified, the group traffic protection keys can be refreshed, and the Policy Token can be updated. main character energy 👑

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

3.4. Group Data Policy 🍓

The Data SA is the ultimate consumer of the group keys. Its data field tells you which keys and mechanisms get used for communication between group members. Lots of protocols can use group keys, from simple security apps that only need a key for encryption and/or integrity protection, all the way up to more complex configurable security protocols like IPsec and Secure Real-time Transport Protocol (SRTP) [RFC3711] 🔐

The Data SA mechanisms are sequenced from "inside" to "outside." So the first Data SA defined in a policy token has to act on the raw data, and any Data SA specified after that gets applied in turn. it's like layers, bestie 🧅

DataProtocol ::= Protocol

4. Security Considerations 💀

This document specifies the structure for a group policy token. Because of that, 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 on a secure CMS implementation, a signature mechanism of appropriate strength for the group using the policy token, and secure, sufficiently strong keys. On top of that, it relies on knowing a well-known Group Owner as the root of policy enforcement. this part is SERIOUS, not optional 😭

Also, while the Group Owner may list alternate mechanisms for various functions, the group is only as strong as its weakest accepted mechanism. So the Group Owner is responsible for providing only acceptable security mechanisms. no weak links allowed 🔥

5. IANA Considerations 🎀

The following object identifiers have been assigned:

  • id-ct-msec-token OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.1.1
  • id-securitySuiteOne OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.2.1
  • id-GSAKMPv1RegistrationProtocol OBJECT IDENTIFIER::= 1.3.6.1.5.5.12.3.1
  • id-GSAKMPv1DeRegistrationProtocol OBJECT IDENTIFIER::= 1.3.6.1.5.5.12.3.2
  • id-GSAKMPv1Rekey OBJECT IDENTIFIER::= 1.3.6.1.5.5.12.3.3
  • id-rekeyNone OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.4.1
  • id-rekeyMethodGSAKMPLKH OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.4.2
  • id-reliabilityNone OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.5.1
  • id-reliabilityResend OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.5.2
  • id-reliabilityPost OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.5.3
  • id-subGCKSSchemeNone OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.6.1
  • id-subGCKSSchemeAutonomous OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.6.2
  • id-genericDataSA OBJECT IDENTIFIER ::= 1.3.6.1.5.5.12.7.1

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

6. References 📚

6.1. Normative References

  • [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006.
  • [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
  • [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
  • [X.208] Recommendation X.208, Specification of Abstract Syntax Notation One (ASN.1), 1988.
  • [X.660] Recommendation X.660, Information Technology ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules (DER), 1997.

6.2. Informative References

  • [HCLM00] Harney, H., Colegrove, A., Lough, P., and U. Meth, "GSAKMP Token Specification", Work in Progress, February 2003.
  • [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
  • [RFC3740] Hardjono, T. 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] Hardjono, T., Harney, H., McDaniel, P., Colegrove, A., and P. Dinsmore, "Group Security Policy Token: Definition and Payloads", Work in Progress, August 2003.

7. Acknowledgements 🫶

huge thank yous to everyone who made this spec so much better 💜 Uri Meth, whose knowledge of GSAKMP and tokens was deeply appreciated, and who also helped get this document submitted. Peter Lough, Thomas Hardjono, Patrick McDaniel, and Pete Dinsmore for their work on earlier versions of policy tokens. George Gross, for pushing for a well-specified, extensible policy token. And Rod Fleischer, for catching implementation issues 🙌

The following technical works influenced the design of the Group Security Policy Token: [HCLM00], [HCM01], and [HHMCD01] 🌈

Appendix A. Core Policy Token ASN.1 Module 🧚

PolicyToken
    {1.3.6.1.5.5.12.0.1}

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
}

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

DataProtocol ::= Protocol

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

END

Appendix B. GSAKMPv1 Base Policy 🍓

This appendix gives you the data structures needed when GSAKMP exchanges are used as the GroupMngmtProtocol for the registration, de-registration, and/or Rekey SAs. This GSAKMP Base Policy spec assumes you already know GSAKMP 🧠

B.1. GSAKMPv1 Registration Policy 💅

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

id-GSAKMPv1RegistrationProtocol
                   OBJECT IDENTIFIER::= {1.3.6.1.5.5.12.3.1}

The registration policy for GSAKMP gives you four things: 1) info on authorizations for group roles, 2) access control info for group members, 3) the mechanisms used in the registration process, and 4) info on which transport the GSAKMP registration exchange will use. so much info, so little time 🦋

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

B.1.1. Authorization

okay so joinAuthorization is basically the guest list for the group 💅 It tells you who's allowed to be a Group Controller Key Server (GC/KS) and a sub-GC/KS, and it can also say if there are limits on who gets to send data in a group 🔥

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

The authorization info is an access control list 📝 It has the entity name plus the info about which certification authority is acceptable for that entity's certificate. So it's giving "who you are AND who vouched for you" 🫶

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

groupEntity is defined by a type and a value 🧚 The types are integers that line up with the GSAKMP Identification types. And when part of a defined name type is filled with an "*", that's a wildcard meaning any valid choice for that field. This lets you write one authorization rule for a whole set of related names, which is so efficient it's iconic 🦋

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

The certificate authority is identified by the X.509 [RFC3280] key identifier 🔑

     CertAuth ::= KeyIdentifier

Senders in a group can either be all (no sender restrictions, everyone's invited 🎀) or an explicit list of the members who are allowed to send data 🌸

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

B.1.2. AccessControl

okay next up is joinAccessControl, which is the info on who's allowed to be a Group Member 🦋 The access control list is a set of permissions the member has to satisfy, plus a list of name rules and the certificate authority each one has to satisfy. You can also throw in a list of exclusions if you want an extra layer of drama 🙈

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

The permissions that are available to start with are an abstract set of numeric levels 🔢 How they get interpreted is up to each community, so it's very much a "you do you" situation 💜

     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

okay so joinMechanisms is where you pick which GSAKMP mechanisms are allowed for a particular group 🎀 From a policy perspective, any set of JoinMechanism is acceptable, so no judgment here 🫶

     JoinMechanisms ::=  SEQUENCE OF JoinMechanism

Each set of mechanisms used in the GSAKMP Registration can be either explicitly spelled out, or it can be a pre-defined security suite 🧁

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

B.1.3.1. alaCarte

so the explicitly defined one is called alaCarte 🍓 You get to define a mechanism for the signature, the key exchange algorithm, the key wrapping algorithm, the type of acknowledgement data, and the config data for setting timeouts. It's basically building your own security outfit, piece by piece 👗✨

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

The signature definition needs you to specify the signature algorithm used for message signing 💅 The INTEGER that defines the choice lines up with the GSAKMP Signature type.

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

The INTEGER for hashAlgorithm maps to the GSAKMP Nonce Hash type values, and that algorithm is what gets used when computing the combined nonce 🔥

The key exchange algorithm needs an integer to define the GSAKMP key creation type, and it might also need some extra per-type data 🧚

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

The keyWrap is the algorithm used to wrap the group key(s) and the policy token (if one is included) 🔐 The integer lines up with the GSAKMP encryption type.

   KeyWrap ::= INTEGER

Data might get sent back in a GSAKMP Key Download ACK/Failure message 📬 The type of data a group needs is specified by AckData. No such field is currently supported or required, so this one's literally a "nothing to see here" moment 🙈

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

OpInfo holds the config data for how GSAKMP registration operates ⏰ timeOut is how long a sent message can go before it's considered misrouted or lost. It's written as the timestamp type LifeDate, which was defined earlier in the core token. terse tells a GC/KS whether the group should run in terse (TRUE) or verbose (FALSE) mode 💬 The optional timestamp field says whether anti-replay protection uses a timestamp (TRUE) or a nonce (FALSE). If the field is missing, nonces are the default for GSAKMP registration, so it's not a big deal either way 💜

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

B.1.3.2. suite

if the mechanism choice for the join is a predefined security suite, then it's identified by an OBJECT IDENTIFIER (OID) 🦋 Other security suites can be defined somewhere else by a spec and by registering an OID 📚

   SecuritySuite ::= OBJECT IDENTIFIER

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

     id-securitySuiteOne  OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.2.1}

B.1.4. Transport

transport tells you what protocol GSAKMP should ride over 🚀 The udpRTJtcpOther choice means the GSAKMP Request to Join message goes over UDP, and every other group establishment message goes over TCP. It's a little split-the-difference, but it's giving efficiency 💅

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

B.2. GSAKMPv1 Registration ASN.1 Module

okay, here's the whole registration module in one place so you can see how all the pieces fit together 🧩 It's a lot, but it's giving complete picture 💖

   GSAKMPv1RegistrationSA
       {1.3.6.1.5.5.12.0.2}

   DEFINITIONS IMPLICIT TAGS ::=

   BEGIN
     EXPORTS
       GCKSName;

     IMPORTS
       LifeDate
         FROM PolicyToken {1.3.6.1.5.5.12.0.1}

       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::= {1.3.6.1.5.5.12.7}

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

   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

   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 ::= {1.3.6.1.5.5.12.2.1}

   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,
     timestamp BOOLEAN OPTIONAL
   }

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

   END

B.3. GSAKMPv1 De-Registration Policy

okay so GSAKMP de-registration is the way you tell 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 gets used in the core token 🎀

   id-GSAKMPv1DeRegistrationProtocol    OBJECT IDENTIFIER::=
   {1.3.6.1.5.5.12.3.2}

The de-registration policy gives you the mechanisms needed for the de-registration exchange messages 📨 It also says whether the exchange runs in terse (TRUE) or verbose (FALSE) mode, plus which transport the GSAKMP de-registration messages use 🚀

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

The policy that decides which mechanisms the de-registration exchange needs is defined by leaveMechanisms 🧚 It's specified as:

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

The INTEGER for sigAlgorithm maps to the GSAKMP Signature type values, and that algorithm set is the one to use for message signing ✍️

The INTEGER for hashAlgorithm maps to the GSAKMP Nonce Hash type values, and that algorithm is what gets used when computing the combined nonce 🔥

cA is a trust point that the signer's certificate has to certify off of 🔑 It's identified by the Public Key Infrastructure for X.509 Certificates (PKIX) KeyIdentifier [RFC3280] type.

transport gives you the expected transport for GSAKMP de-registration messages 🦋 To start, the policy for a group will be either UDP or TCP.

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

B.4. GSAKMPv1 De-Registration ASN.1 Module

and last but not least, here's the de-registration module, which is the smaller, cleaner cousin of the registration one 💜

   GSAKMPv1DeRegistrationSA
       {1.3.6.1.5.5.12.0.3}

   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::= {1.3.6.1.5.5.12.3.2}

   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 ✨

okay so this is the rekey policy, the part that says how and when the group gets fresh keys 🔑💖. when GSAKMP is the Rekey Protocol for the Group, you should use this object identifier in the core token as the rekey protocol:

id-GSAKMPv1Rekey     OBJECT IDENTIFIER::= {1.3.6.1.5.5.12.0.4}

bestie, the GSAKMP rekey policy is a whole package 🎀. it gives you the authorization info, the mechanisms for rekey messages, the rekey event definitions (which decide when the GC/KS sends a rekey message 💌), the protocol or method the rekey event uses, the rekey interval that lets a member notice when the rekey process has failed, a reliability indicator for how the rekey gets delivered more reliably (if it does at all 🙈), and finally how subordinate-GC/KSes handle rekey. it also describes the specific rekey policy methods "None" and "GSAKMP LKH REKEY". iconic 👑

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 for the mechanisms needed to process rekey messages is defined by RekeyMechanisms. it's specified like this:

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

so the INTEGER for sigAlgorithm maps to the GSAKMP Signature type values 🖊️. that algorithm set is what gets used for signing messages. and the INTEGER for hashAlgorithm maps to the GSAKMP Nonce Hash type values, which is the algorithm used when computing the combined nonce 🌸.

B.5.3. Rekey Event Definition ⏰

Rekey Event Definition gives the GC/KS info about the system requirements for sending rekey messages 💅. it lets you define the rekey event in time, or in terms of events (number of de-registration notifications is one example), or both at once. like, "after x de-registrations or 24 hours, whichever comes first" 😭. that's the vibe.

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 is the maximum time a group should exist between rekeys ⏳. no clock synchronization needed here, because it's measured against a local clock. either the GC/KS clock (for sending rekey messages) or a member clock (for figuring out whether a message got missed) 🕰️.

the INTEGER for the event is how many events a group should sustain before a rekey message gets sent. so it defines the events between rekeys 🔁. de-registration notifications are a relevant example.

TimeAndEvent is basically a couple of the LifeDate and Integer policies 💜.

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

B.5.4. Rekey Methods 🛠️

the rekey method says how the rekey is going to be accomplished. it's specified as:

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

rekeyMethodType defines which rekey method the group uses 🎯. and rekeyMethodInfo gives the GMs the info they need to operate in the correct rekey mode 🦋.

B.5.4.1. Rekey Method NONE 🙅‍♀️

a group that works without any rekey protocol supporting it is covered by the rekeyMethodType NONE. there's no RekeyMethodNoneInfo tied to this option 🌈.

id-rekeyNone OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.4.1}

RekeyMethodNoneInfo ::= NULL

B.5.4.2. Rekey Method GSAKMP LKH 🗝️

the GSAKMP protocol spec defined its own take on the Logical Key Hierarchy (LKH) protocol as a rekey method. this method is identified by the following values 🧚.

id-rekeyMethodGSAKMPLKH OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.4.2}

RekeyMethodGSAKMPLKHInfo ::= INTEGER

the GSAKMP LKH method needs a gsakmp type value to identify the cryptographic algorithm used to wrap the keys 🎁. that value maps to the GSAKMP encryption type.

B.5.5. Rekey Interval ⏱️

rekey interval is the maximum delay the GM should see between valid rekeys 💫. it's how you make sure the GM is synced, from a key management point of view, with the rest of the group 🫶. it's defined as a time/date stamp.

B.5.6. Rekey Reliability 📬

the rekey message in GSAKMP is a single push message 📣. and yeah, there are reliability concerns with non-acknowledged messages like that (i.e., message exchange) 😬. the Reliability policy defines the mechanism used to deal with those concerns.

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

the reliability mechanism is defined by an OBJECT IDENTIFIER. the info needed to run that mechanism lives in reliabilityMechContent, which is an OCTET STRING (as before) 🍓.

B.5.6.1. Rekey Reliability Mechanism None 🌙

in networks with adequate reliability, you may not need a mechanism to improve reliability of the rekey message at all. for those networks, the ReliabilityMechanism NONE is appropriate 🌷.

id-reliabilityNone OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.5.1}

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 those networks the ReliabilityMechanism RESEND is potentially appropriate. this mechanism has the GC/KS repeatedly sending out the same message 📨📨📨.

id-reliabilityResend OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.5.2}

ReliabilityResendInfo ::= INTEGER

the INTEGER value in ReliabilityResendInfo says how many 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 makes it generally available 🌐. this is the reliabilityPost method, so iconic.

id-reliabilityPost OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.5.3}

ReliabilityContentPost ::= IA5String

the IA5String for ReliabilityPost is the identifier of the posting site and the rekey message 🦋.

B.5.7. Distributed Operation Policy 🌍

the policy for how the GC/KS and the S-GC/KS relate to each other in distributed operations is defined as SubGCKSInfo. it's a couple of a subGCKSScheme and some info about that scheme in sGCKSContent 💜.

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

B.5.7.1. No Distributed Operation 🚫

if the group isn't going to use S-GC/KS, then that scheme would be SGCKSSchemeNone 🙃.

id-subGCKSSchemeNone OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.6.1}

SGCKSNoneContent ::= NULL

B.5.7.2. Autonomous Distributed Mode 🦄

if the group is going to use S-GC/KS as defined in the GSAKMP spec under Autonomous mode, then that scheme would be SGCKSAutonomous 🌟.

id-subGCKSSchemeAutonomous
                     OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.6.2}

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

the policy info needed for autonomous mode is a list of authorized S-GC/KSes and restrictions on who they're allowed to serve 📋. the domain field, which holds those restrictions, is NULL for this version 💅.

B.6. GSAKMPv1 Rekey Policy ASN.1 Module 📜

this is the full ASN.1 module for the rekey policy, so here it is in one go 🎀.

GSAKMPv1RekeySA
     {1.3.6.1.5.5.12.0.4}

DEFINITIONS IMPLICIT TAGS ::=

BEGIN

  IMPORTS
    GCKSName
      FROM GSAKMPv1RegistrationSA  {1.3.6.1.5.5.12.0.2}
    LifeDate
      FROM PolicyToken  {1.3.6.1.5.5.12.0.1};

id-GSAKMPv1Rekey OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.0.4}

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
}

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 ::= {1.3.6.1.5.5.12.4.1}

RekeyMethodNoneInfo ::= NULL

-- REKEY METHOD GSAKMP LKH --

id-rekeyMethodGSAKMPLKH OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.4.2}

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

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

-- RELIABILITY MECHANISM NONE --

id-reliabilityNone OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.5.1}

ReliabilityContentNone ::= NULL

-- RELIABILITY MECHANISM RESEND --

id-reliabilityResend OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.5.2}

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

-- RELIABILITY MECHANISM POST --

id-reliabilityPost OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.5.3}

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

id-subGCKSSchemeNone OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.6.1}

SGCKSNoneContent ::= NULL

id-subGCKSSchemeAutonomous OBJECT IDENTIFIER ::= {1.3.6.1.5.5.12.6.2}

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

END

Appendix C. Data SA Policy 🌸

okay this next bit is the Data SA 💖. the Data SA gives you the data structures needed to protect the data that group members swap with each other 📦. this appendix defines the data structures for a simple, generic security application that uses fixed security mechanisms 🔒. and the only thing a Data SA needs is for the keys delivered by the registration and rekey protocols to get mapped to the service that's using them 🗝️✨.

C.1. Generic Data Policy ✨

bestie, this one is the Generic Data Policy 🎀 and its identifier is:

id-genericDataSA OBJECT IDENTIFIER :: = {1.3.6.1.5.5.12.7.1}

okay so if the security application uses an authentication mechanism 🔐, the key identifier (kMKeyID) that the key management protocol uses gets listed, plus an optional key expiration date. same deal for encryption 💜: if there's an encryption mechanism, you get the encryption key identifier and an optional key expiration date (keyExpirationDate). it's giving tidy, no cap 💅

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

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

C.2. Generic Data Policy ASN.1 Module 🧚

this is the full ASN.1 module, the official little rulebook for the Generic Data Policy 📖 it's built around the GenericDataSA module at {1.3.6.1.5.5.12.0.5}, and it's obsessed with IMPLICIT TAGS 💖

GenericDataSA
    {1.3.6.1.5.5.12.0.5}

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

    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 ::= {1.3.6.1.5.5.12.7.1}

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

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

END

Authors' Addresses 🦋

the two authors are from SPARTA, Inc. and they both chill at the same Columbia, MD address 🌸 here's where you can find them:

Andrea Colegrove
SPARTA, Inc.
7110 Samuel Morse Drive
Columbia, MD 21046

Phone: (443) 430-8014
Fax:   (443) 430-8163
EMail: acc@sparta.com


Hugh Harney
SPARTA, Inc.
7110 Samuel Morse Drive
Columbia, MD 21046

Phone: (443) 430-8032
Fax:   (443) 430-8181
EMail: hh@sparta.com

Copyright (C) The Internet Society (2006).

this doc is subject to the rights, licenses and restrictions in BCP 78 🔒 and, except where BCP 78 says otherwise, the authors keep all their rights 💅

the doc and everything in it is 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 😭 so no promises, just vibes.

Intellectual Property 🌈

the IETF doesn't take a position on whether any Intellectual Property Rights or other rights that someone might claim over the tech in this doc are valid or how far they go 🧐 it also doesn't say licenses are or aren't available, and it hasn't made any independent effort to find out what rights might exist 🤷‍♀️ if you want the procedures for rights in RFC docs, check out BCP 78 and BCP 79 📚

copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that might be available, and the results of any attempt to get a general license or permission for implementers or users to use these proprietary rights can all be found in the IETF's online IPR repository at http://www.ietf.org/ipr 🔍

the IETF also invites anyone to tell it about any copyrights, patents or patent applications, or other proprietary rights that might cover technology needed to implement this standard 🫶 send that info to the IETF at ietf-ipr@ietf.org ✨

Acknowledgement 💖

funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) 🎉 thank u, IASA, you're iconic 👑

the end, bestie 🌈🦋💜

📦 where this page comes from