IEEE 1609.2b:2019 pdf free download – IEEE Standard for Wireless Access in Vehicular Environments – Security Services for Applications and Management Messages
NOTE—The editing instructions contained in this amendment define how to merge the material contained therein intothe existing base standard and its amendments to form the comprehensive standard.
The editing instructions are shown in bold italic. Four editing instructions are used: change, delete, insert, and replace.Change is used to make corrections in existing text or tables. The editing instruction specifies the location of thechange and describes what is being changed by using strikethrough (to remove old material) and underscore (to addnew material). Delete removes existing material. Insert adds new material without disturbing the existing material.Insertions may require renumbering.If so, renumbering instructions are given in the editing instruction.Replace is usedto make changes in figures or equations by removing the existing figure or equation and replacing it with a new one.Editing instructions, change markings, and this NOTE will not be carried over into future editions because the changeswill be incorporated into the base standard.
-Signing an application PDU to demonstrate that the sender has authorization to take or request theaction indicated by that application PDU.
-Creating some other form of authorization token,where the intent is to indicate within the contextof a secure session that the signer has a particular set of authorization permissions. This set ofauthorization permissions may then be referred to within the secure session so that requestedactions can be determined to be authorized without the need for each individual action request to besigned.Examples of this authorization token include the CertificateVerify message in the InternetEngineering Task Force (IETF)’s Transport Layer Security standard [B13a，B13b], and theextended authentication PDU defined in ISo 21177 [B14a].
lf a signed SPDU intended for one use could be replayed in a different context and interpreted as if it wereintended for a different use, this would be a security weakness. This standard therefore provides the abilityfor the signer to indicate the intended PDU functional type, so that if an SPDU is received in a context thatis not appropriate to its functional type, that SPDU can be ignored by the receiver. The intent is that aspecification of a design using this standard shall include, for each scenario where a signed SPDU is used,an indication of the functional type to be used.
Currently supported PDU functional types are application PDU(APDU),TLS Handshake, and ISO 21177extended authentication. It is intended that this list is extended if additional forms of authorizationinvolving 1609.2 SPDUs are defined in the future by some specification organization.
This approach allows an EncryptedData to be created for recipients that already know the data encryptionkey, for recipients that do not already know the data encryption key, or for a combination of the two typesof recipients.
ln the Sec-EncryptedData.request primitive of 9.3.11.1,the SDEE indicates to the SDS whether to use anephemeral or static data encryption key by providing or not providing the Data Encryption Key Typeparameter. If the SDEE requested an ephemeral data encryption key, the SDS may return a cryptomaterialhandle (see 4.3.3 and 9.2.2) for that data encryption key in the corresponding Sec-EncryptedData.confirmprimitive to enable that data encryption key to be reused if desired.
In the Sec-EncryptedDataDecryption.confirm primitive of 9.3.13.2, the SDS may provide a CryptomaterialHandle for the data encryption key in the Data Encryption Key CMH parameter.This enables the SDEEthat receives this primitive to store the CMH for later use.