IEEE MEDIA INDEPENDENT HANDOVER DCN: MuGM Title: TGd Message Signing Proposal Date Submitted: Presented at IEEE d session #53 Authors or Source(s): Stephen Chasko, Michael Demeter (Landis+Gyr Abstract: A proposal for providing group multicast message signature keys, signatures and verification keys MuGM1

2 IEEE presentation release statements This document has been prepared to assist the IEEE Working Group. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE The contributor is familiar with IEEE patent policy, as stated in Section 6 of the IEEE-SA Standards Board bylaws and in Understanding Patent Issues During IEEE Standards Development Section 6 of the IEEE-SA Standards Board bylawshttp://standards.ieee.org/guides/bylaws/sect6-7.html#6http://standards.ieee.org/board/pat/faq.pdf MuGM

Multicast Message Signatures Message source requests certificates for public key Message source provides certificates to destination devices Multicast Messages are signed with message source using private key Multicast Message’s integrity and proof of origin is verified by verifying message signature with message source public key On Receipt of signed multicast message there is an optional response indicating validity of signature Message source requests certificates for key updates Message source provides updates of certificates to destination devices (with overlap period) MuGM3

Message Signature The message content is signed using elliptical curve cryptography. An ECDSA signature (secp256r1) of the message content will be generated. This is a 512 bit signature (64 bytes) MuGM4

Signature Verification The signature is verified using the message source signature verification key. The endpoints might have more than one key used for signature verification. This is to allow for key updates to happen in an efficient manner for large systems. The message source will identify which key is to be used for the multicast message so that verification will utilize the correct key for signature verification MuGM5

Certificate Generation A root of trust will exist for the multicast nodes. The root of trust is envisioned to be a certificate authority. X.509 format certificates will be utilized. The root of trust will establish the binding between the identity of the message source and the public/private key pair used for signature generation and verification. The certificate will include the identity of the certificate authority, the identity of the message source, the public key in use and the expiration date of the certificate and the certificate authorities signature. For an endpoint to trust the certificate it must have the certificate authority public MuGM6

Certificate Distribution The initial certificates for multicast signature verification are distributed to multicast destinations as part of the provisioning process to the multi-node network. The certificates will include the certificate authority certificate used to verify the initial and updated certificates. There will also be one or more certificates that are bound to the identity of the multicast source. As part of the key update or revocation process, a new certificate will be provided to multicast destinations using the multicast mechanism. There needs to be a mechanism for multicast destinations to acknowledge the receipt of the multicast message MuGM7

Certificate Revocation When there is reduced trust in a certificate a mechanism will be provided to revoke the certificate from service. This mechanism will utilize the multicast messaging mechanism. Multicast destinations will need to provide a reply that indicates they have successfully revoked the certificate MuGM8

New Entities entities: If a new entity is introduced for proposed d solutions, then address the relation, location, and interface with other entities. Reference points: if new reference point(s) are introduced, then define and identify the reference point(s) w.r.t the MIHF communication model specified in the spec. Data fields: if for protected messages, new data fields are introduced, then specify them in data format MuGM9 From Proposal Guidelines

MIH_Certificate_PUSH.request used to send a certificate from a PoS to a destination PoS or PoA Symantics: MIH_Push_Certificate.Request {Destination Identifier, Certificate} When Generated: For initial provisioning of certificates or for certificate updates. Effect on Receipt: Certificate signature is verified and result of verification is provided back to push requester. After verification, validated certificate public keys within their expiration period can be utilized for multicast message MuGM10 NameData TypeDescription Destination IdentifierMIHF_IDIdentifies the invoker CertificateCERTIFICATEX.509 certificate

MIH_Certificate_PUSH.response Use: Acknowledge receipt of a certificate from a PoS Symantics: MIH_Push_Certificate.Response {Destination Identifier, Certificate Status} When Generated: After receipt and certificate inspection. Effect on Receipt: Success status indicates the PoS can manage device as being capable of received signed multicast messages MuGM11 NameData TypeDescription Destination IdentifierMIHF_IDIdentifies the invoker Certificate Serial NumberCERTIFICATE_SERIAL_ NUMBER X.509 certificate subfield – serial number Certificate StatusCERTIFICATE_STATUSIndicates whether a certificate has been verified and is now in use by the receipient.

MIH_Revoke_Certificate.Request used to revoke a certificate previously issued by a PoS and sent to a multicast group of PoS and/or PoA Symantics: MIH_Revoke_Certificate.Request {Destination Identifier, Certificate} When Generated: On deprecation of a public/private key pair. Effect on Receipt: After verification of the message signature, the certificate being revoked is deleted from PoS. A response is then sent indicating status of revocation operation MuGM12 NameData TypeDescription Destination IdentifierMIHF_IDIdentifies the invoker Certificate Serial NumberCERTIFICATE_SERIAL_ NUMBER X.509 certificate subfield – serial number

MIH_Revoke_Certificate.Response used to acknowledge receipt of a revocation request from a PoS Symantics: MIH_Revoke_Certificate.Response {Destination Identifier, Certificate Status} When Generated: After receipt and processing of revoke request. Effect on Receipt: If revocation message signature is valid, then PoS changes status of revoked certificate. Result of request is provided in the REVOCATION_STATUS MuGM13 NameData TypeDescription Destination IdentifierMIHF_IDIdentifies the invoker Certificate StatusCERTIFICATE_STATUSIndicates whether a certificate has been revoked.

Message signature The S Bit in the MIH header is set A signature TLV is included The definition and format of signature TLV is described in the following slides MuGM14

Security Capabilities A new option is added to the existing security capabilities defined in the standard MIH_SEC_CAP – Signed Multicast MuGM15

SIGNATURE A new security data type will be added Data Type: SIGNATURE Derived From: Octet String Description: Provides a 64 byte ECDSA signature of the message MuGM16

CERTIFICATE A new security data type will be added Data Type: CERTIFICATE Derived From: Octet String Description: Provides a X.509 Certificate MuGM17

CERTIFICATE_SERIAL_NUMBER A new security data type will be added Data Type: CERTIFICATE_SERIAL_NUMBER Derived From: Octet String Description: Provides X.509 formatted certificate serial number which are unique by certificate authority MuGM18

CERTIFICATE_STATUS A new security data type will be added Data Type: CERTIFICATE STATUS Derived From: enumerated Definition: This indicates the status of the certificate being pushed or revoked 0 – Not Present – indicates that certificate is not present 1 – Certificate Valid – indicates that certificate is present and that associated public key is being used to verify signatures 2 – Certificate Revoked 3 - Certificate Expired MuGM19

Type Values for TLV encoding A new type value for TLV encoding is required TLV Type Name: Signature TLV Type Value: 76 Data Type: SIGNATURE TLV Type Name: Certificate TLV Type Value: 77 Data Type: CERTIFICATE MuGM20

Type Values for TLV encoding, cntd A new type value for TLV encoding is required TLV Type Name: CertificateStatus TLV Type Value: 78 Data Type: CERTIFICATE_STATUS TLV Type Name: CertificateSerialNumber TLV Type Value: 79 Data Type: CERTIFICATE_SERIAL_NUMBER MuGM21

Gaps in proposal Critical to this proposal and necessary for its completeness is a multicast mechanism. This proposal is based on the securing of the messaging not on the underlying multicast mechanism. Confidentiality is not part of the security mitigations provided through the message signing proposal. For completeness of addressing the proposal requirements a separate confidentiality mechanism is necessary MuGM22

The solution will support the following features PoS to MN multicast PoS (or MIH non-PoS) to PoS multicast Handling of duplicate multicast MIH data Authentication Data Integrity Confidentiality Availability Key Management MuGM23

Proposal Guideline - Proposal Characterization List MuGM24 Supported FunctionalityRequirement # in TR document Note Multicast Communication Req Not addressed Addressing Req Not addressed Multicast Transport Req2.1.3.{1,2} Not addressed Group Management Req Not addressed Security Requirements Req2.1.5.{1,2} Integrity, authenticity and key management are described in detail Transparency to MIH Users Req Impact on MIH messaging is described Reduced signaling Req Minimal signaling prescribed Scalability Req2.2.3.{1,2} Protocol designed for low capacity devices and networks Backward compatibility Req2.3.1.{1,2,3} Devices are not required to support secure multicast which would allow for the additional messaging to be backward compatible

References Ohba, “Security TG Call for Proposals”, IEEE P Media Independent Handover Services, MuGM, Sept, 19, 2012 Oliva, Corujo, Guimaraes, “Requirements Document for TGd”, IEEE P Media Independent Handover Services, MuGM, Sept 18, 2012 RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List Profile, May 2008 IEEE Standard for local and metropolitan area networks, Part 21 Media Independent Handover Services. IEEE a MuGM25