1 / 10

IEEE 1609.1 Status Apr 6 2010

IEEE 1609.1 Status Apr 6 2010. Alastair Malarky MARK IV IVHS amalarky@ivhs.com http://www.ivhs.com 905-624-3020 x 1203. 1609.1 Status. Draft 2.0 in process About 70% of comments assessed and decisions implemented in draft Request based TA sequence, with security, implemented in draft

hei
Télécharger la présentation

IEEE 1609.1 Status Apr 6 2010

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IEEE 1609.1 StatusApr 6 2010 Alastair Malarky MARK IV IVHS amalarky@ivhs.com http://www.ivhs.com 905-624-3020 x 1203

  2. 1609.1 Status • Draft 2.0 in process • About 70% of comments assessed and decisions implemented in draft • Request based TA sequence, with security, implemented in draft • PAR • Update from last meeting approved

  3. Status – Key Items • Security review / additions still outstanding • William is still working on funding for this. • Security approach could have significant implication on identities and other items • No fundamental changes foreseen otherwise • Updated to reflect sponsor versions of dot3 + Dot4 + change that will result from 802.11p D11.0 (PeerMACAddress on TA primitives)

  4. Request based TA • Document with new section sent out on 5 Apr • Concepts discussed at last meeting implemented • Existence of a Timing Management Function • for purpose of standard • only the interactions between the function and WAVE services are defined • Use of nonce and signed TA to limit attacker window of opportunity • Use of VSIE for signature • Remote device can decide if it wishes signed TA

  5. Request TA 1 2 3 4 5 6

  6. Request based TA 1Request uses WME-ManagementDataService • Creates VSA • includes nonce if signed TA wanted • Nonce changes every request • nonce size TBD – waiting for security review • 10 bytes used for placeholder 2 On receipt of VSA , WME gets UTC Time • Use for TA if unsigned TA requested • Use to create signed data if signed TA requested

  7. Request based TA 3 Create signed data payload for VSIE if required • Signed data payload contains 3 elements • Nonce is as per received request • ValidUTCStart is earliest valid UTC for TA information • ValidUTCStart + ValidUTCWindow is latest valid UTC for TA information • VSIE identified as 1609.1 field

  8. Request based TA 4 Can re-request UTC Time if signed TA being used • Use this to populate TA fields • This ensures TA data is most accurate 5 Send TA with/without signature • Unicast or broadcast ?

  9. Request based TA 6 Possible receiver validation checks • Response received within receiver defined window • UTC computed using TA fields lies inside UTC window defined by transmitter • Nonce inside signed data payload matches request • Signature is valid

  10. 1609.1 Schedule • Estimate at least 1 more month for full draft • May be later depending on security review timeline and level of changes required

More Related