IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN: 21-12-0156-00-MuGM Title: 802.21 TGd Message Signing Proposal Date Submitted: Presented at IEEE 802.21d session.

IEEE 802.21 MEDIA INDEPENDENT HANDOVER

DCN: 21-12-0156-00-MuGM

Title: 802.21 TGd Message Signing Proposal

Date Submitted:

Presented at IEEE 802.21d 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.

21-12-0156-00-MuGM 1

2

IEEE 802.21 presentation release statementsThis document has been prepared to assist the IEEE 802.21 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 802.21.

The contributor is familiar with IEEE patent policy, as stated in Section 6 of the IEEE-SA Standards Board bylaws <http://standards.ieee.org/guides/bylaws/sect6-7.html#6> and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/faq.pdf> 

21-12-0156-00-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)

21-12-0156-00-MuGM 3

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)

21-12-0156-00-MuGM 4

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.

21-12-0156-00-MuGM 5

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

21-12-0156-00-MuGM 6

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.

21-12-0156-00-MuGM 7

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.

21-12-0156-00-MuGM 8

New 802.21 Entities

• 802.21 entities: If a new 802.21 entity is introduced for proposed 802.21d solutions, then address the relation, location, and interface with other 802.21 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 802.21 spec.

• Data fields: if for protected messages, new data fields are introduced, then specify them in 802.21 data format.

21-12-0156-00-MuGM 9

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.

21-12-0156-00-MuGM 10

Name Data Type Description

Destination Identifier MIHF_ID Identifies the invoker

Certificate CERTIFICATE X.509 certificate

MIH_Certificate_PUSH.responseUse: 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.

21-12-0156-00-MuGM 11

Name Data Type Description

Destination Identifier MIHF_ID Identifies the invoker

Certificate Serial Number CERTIFICATE_SERIAL_NUMBER

X.509 certificate subfield – serial number

Certificate Status CERTIFICATE_STATUS Indicates 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.

21-12-0156-00-MuGM 12

Name Data Type Description

Destination Identifier MIHF_ID Identifies the invoker

Certificate Serial Number CERTIFICATE_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.

21-12-0156-00-MuGM 13

Name Data Type Description

Destination Identifier MIHF_ID Identifies the invoker

Certificate Status CERTIFICATE_STATUS Indicates 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.

21-12-0156-00-MuGM 14

Security Capabilities

A new option is added to the existing security capabilities defined in the standard

MIH_SEC_CAP – Signed Multicast

21-12-0156-00-MuGM 15

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

21-12-0156-00-MuGM 16

CERTIFICATE

A new security data type will be added

Data Type: CERTIFICATE

Derived From: Octet String

Description: Provides a X.509 Certificate

21-12-0156-00-MuGM 17

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.

21-12-0156-00-MuGM 18

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

21-12-0156-00-MuGM 19

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

21-12-0156-00-MuGM 20

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

21-12-0156-00-MuGM 21

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.

21-12-0156-00-MuGM 22

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

21-12-0156-00-MuGM 23

Proposal Guideline - Proposal Characterization List

21-12-0156-00-MuGM 24

Supported Functionality Requirement # in TR document

Note

Multicast Communication Req2.1.1.1 Not addressed

Addressing Req2.1.2.1 Not addressed

Multicast Transport Req2.1.3.{1,2} Not addressed

Group Management Req2.1.4.1 Not addressed

Security Requirements Req2.1.5.{1,2} Integrity, authenticity and key management are described in detail

Transparency to MIH Users Req2.2.1.1 Impact on MIH messaging is described

Reduced signaling Req2.2.2.1 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 P802.21 Media Independent Handover Services, 21-12-0099-01-MuGM, Sept, 19, 2012

Oliva, Corujo, Guimaraes, “Requirements Document for TGd”, IEEE P802.21 Media Independent Handover Services, 21-12-0091-06-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 802.21a-2012

21-12-0156-00-MuGM 25