Logo etsi

ETSI's Bug Tracker

Notice: information submitted on the ETSI issue Tracker may be incorporated in ETSI publication(s) and therefore subject to the ETSI IPR policy.

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0006969

SECURITY

Base Spec

public

24-03-2015 10:10

30-08-2016 13:48

Reporter

Norbert Bissmeyer

Assigned To

Priority

normal

Severity

feature

Reproducibility

always

Status

new

Resolution

open

Platform

OS Version

Product Version

Target Version

Fixed in Version

Summary

0006969: Request of unrecognized AA certificate create high channel load when all receivers reply with a certificate chain

Description

As specified in the CAM profile of ETSI TS 103 097 v1.1.20 section 7.1 "If the ITS-S finds a HashedId3 of its own, currently used authorization authority in that list, it shall include a signer_info field of type certificate_chain". This leads to high channel load if several ITS-S send in their next CAM a chain instead of their certificate or digest.
In addition, an attacker can easily misuse this feature to create a DoS in its single-hop communication range.

Steps To Reproduce

Many problems may be mitigated by clever implementations. Maybe, it could be added an informative section to the standard which gives hints how to implement this mechanism in a way, that it is not that easy to misuse it? A list of potential problems should be prepared.
If an ITS-S requests only an AA certificate then the receivers should check if other neighbors have already answered with a chain containing the AA cert then the receiver could omit sending its own certificate chain containing the requested AA cert.

Tags

No tags attached.

Attached Files

Relationships

Notes
(0012850) Denis Filatov (administrator) 26-03-2015 12:33	In my opinion the solution shall be clearly defined in the main standard. It should not be up to implementers to avoid the recomendation. One of the possible solution for that is: 1. The requester must put both, AT and AA digests in the requested certificate list. Other stations, having its AT digest in the list must check if its AA digest is also in the list, if so, it must answer with its AA certificate, if not - with AT one. 2. To avoid sending both, AT and AA certificate in one message, it is better to send only AA because AT was already sent just before. In this case the CAM can be signed with AT digest and AA certificate can be send in the new dedicated header. Perhaps it can be a general respond message to unrecognized certificate request.

Issue History
Date Modified	Username	Field	Change
24-03-2015 10:10	Norbert Bissmeyer	New Issue
25-03-2015 08:34	Norbert Bissmeyer	Description Updated	View Revisions
26-03-2015 12:33	Denis Filatov	Note Added: 0012850

MantisBT 1.2.14 [^]