1 / 11

December 2009 A Malarky, J Moring, W Whyte

December 2009 A Malarky, J Moring, W Whyte. Interim Approach for Secure Timing Advertisements. Introduction.

alec-mccullough
Télécharger la présentation

December 2009 A Malarky, J Moring, W Whyte

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. December 2009A Malarky, J Moring, W Whyte Interim Approach for Secure Timing Advertisements

  2. Introduction • Pending a final timing distribution approach, we agreed Dec 9, 2009 in San Diego to attempt to develop an interim approach in 1609.1 to secure timing distribution that is consistent with future expansion to generalized secure timing distribution • Ability to sign and verify timing info • Minimal operational system impact (e.g., no channel flooding) • Manageable impacts to existing standards • Does not preclude a more robust approach in the future

  3. Generalized Time distribution mechanism • Time on a device is managed by a Time Management Function (TMF) • Either broadcast or response based issuing of TAs possible • 1609.1 interim version is response based • Generalized response based method: • TMF on one device (Requestor) recognizes it has poor time quality, and sends TA which identifies its time and accuracy to act as a request. • TMF on another device (Sender) recognizes Requestor has poor timing and decides to supply better timing • TMF on Sender issues signed TA(s). • TMF on Requestor receives and validates the TA(s) • When appropriate (perhaps after multiple received TAs of sufficient quality) Requestor TMF tells 1609.4 MLME to update local time parameters

  4. Signing Time and Latency • The critical issue in singing TAs is the ability to sign the transmitted Timestamp and Time Advertisement element in the TA frame. • The Timestamp is added at time of transmission, and since the signature can’t be calculated instantaneously, it is not reasonable to sign the actual Timestamp. • Two generalized signing methods considered: • “Post authenticate”: • The values from the previous frame are authenticated with a signature in a subsequent frame • This requires access to the transmitted Timestamp which is added by the 802.11 PHY. • Currently the PHY is not specified to return this in IEEE 802.11-2007, however P802.11v is adding TIME_OF_DEPARTURE to PHYTXSTART.confirm which would support it. • “Pre authenticate”: • The values used in the signature are taken before the frame is transmitted - i.e. a value of TSF Timer prior to Timestamp is obtained.

  5. Interim Solution Summary • Concept of TMF will be added to 1609.1 • 1609.1 will use Pre Authenticate method • Use of either TA or 1609.1 management message to act as request mechanism and signing and verification of signed TA will be added to 1609.1 • Consistent with its scope of remote management • 1609.2/1609.3/1609.4 SAPs and functionality minimally enhanced • All enhancements support future generalized approach • No changes to 802.11 needed with interim approach • Limitations • Uses TSFTimer value prior to actual Timestamp as signed element on the transmitted frame. • Thus there is a (small) time window between secured and unsecured values of timing information over which time could be pulled by an attacker. • Additional refinements may be possible outside 1609.3/1609.4/1609.1

  6. Key: Red text indicates primitive needing update Red arrow indicates new primitive/function Information flow - John please update this to also allow use of 1609.1 management message as a request message

  7. Reference prior figure • TMF on managed device (Requestor) recognizes it has poor time qualityand sends TA to act as request • Also possible (only sent to Remote Manager) to send Timing Request message from 1609.1 message set. • TMFon Sender device reacts. It grabs local TSF time, i.e., Timestamp, and the UTC time estimate including Time Value. • Sender TMF builds the timing info to be signed, and signs it via 1609.2 • Sender TMF triggers a TA to be sent containing signed info. Received TA info is sent to TMF at Requestor. • RequestorTMF validates signed info via 1609.2 • When appropriate (perhaps after multiple received TAs of sufficient quality) RequestorTMF tells 1609.4 MLME to update local time parameters

  8. Signed info • The signed element added to the TA could contain the following: • TSF_low = Timestamp (from GETUTCTIME.cfm) + known min latency in sender (added at TMF) • TimeValue_nom = TimeValue from GETUTCTIME.cfm • TimeError from GETUTCTIME.cfm • Deltamax = allowed max difference (positive only) from signed vs unsigned values in TA. This accounts for latency variation plus possible change in signed TimeValue from GETUTCTIME.cfm to unsigned TimeValue in TA. • <Nonce> from requesting message (e.g. MLMEX-TA.ind) if applicable • On receipt, values in unsigned TA info can be verified to lie in range defined by signed values. • Then the additional uncertainty that can exist at the receiver if unsigned values accepted can only be between -Deltamax to 0. This uncertainty can be included into the values fed to the synchronizing routine. The signature for interim version will be addressed in 1609.1

  9. Changes to existing drafts • 1609.1 • All of Timing Management Function is new • Request message already defined in v1.2 • 1609.2 • Changes to support signing/validating of timing info • 1609.4 • New primitives (MLMEX-SetTime) and functionality to allow TMF to cause time parameters to be updated, rather than using received TA directly • 1609.3 • Change to TimingAdvertisementService.req to allow Vendor Specific content from requesting entity (e.g. signed info from sender, nonce from requestor)

  10. Updates to Primitives in 1609.3 and 1609.4 • John – show change primitives here – just parameters • MLMEX-SetTime (TimeValue, Time Error)

  11. Notes • We know that the Timestamp sent in the actual TA frame is not knowable at the sender to create the signature in the same frame. • Thus the need for the sender signing the TSFTime from GETUTCTIME (invokes 802.11 GETTSFTIME) • The secure timing info (Timestamp, Time Value) is generated by the sender’s TMF from info grabbed from MLME. By the time it reaches the receiver TMF, it will have not only transfer delay, but also signing and stack delays. • See Signed Info page for partial mitigation of this latency • Some aspect of the feature may require further consideration, e.g., • When does the receiver TDF sent a TA? • When does the sender TDF send a TA? • When does the receiver TDF update local time? • These will not be specified in 1609.1 interim solution

More Related