100 likes | 251 Views
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
E N D
IEEE 1609.1 StatusApr 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 • PAR • Update from last meeting approved
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)
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
Request TA 1 2 3 4 5 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
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
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 ?
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
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