fear and loathing at the ietf fear and loathing at the
play

Fear and Loathing at the IETF Fear and Loathing at the IETF (Ten - PowerPoint PPT Presentation

Fear and Loathing at the IETF Fear and Loathing at the IETF (Ten Years with No Pay) (Ten Years with No Pay) Note: Note: NEVER joke about your presentation title with the Panel Chairperson!! NEVER joke about your presentation title with the


  1. Fear and Loathing at the IETF Fear and Loathing at the IETF (Ten Years with No Pay) (Ten Years with No Pay) Note: Note: NEVER joke about your presentation title with the Panel Chairperson!! NEVER joke about your presentation title with the Panel Chairper son!! My apologies to HST My apologies to HST Sepucha_Date_01

  2. IETF Security Standards IETF Security Standards Challenges and Opportunities Challenges and Opportunities Hugh Harney SPARTA, Inc. 7075 Samuel Morse Dr. Columbia, MD, 21046 410-872-1515 x203 Sepucha_Date_02

  3. Agenda Agenda • Are the ground rules changing? – Are we forgetting end to end? – Are we passing adequate policy information? – Are the mechanism flexible enough? Sepucha_Date_03

  4. Are we forgetting end to end system design? Are we forgetting end to end system design? Store and forward systems need • system level mechanisms. – Service desired is secure end to SECURE end. Server – Communications push us to store and forward solutions. Router – Pairwise connections to servers are not end to end secure. ? Peer Router ? Router Peer » Source authentication » Data integrity Router Peer Router Peer » Does the data source really know the access control Router rules? Peer END-TO-END ARGUMENTS IN SYSTEM DESIGN J.H. Saltzer, D.P. Reed and D.D. Clark* Sepucha_Date_04

  5. Adequate policy information? Adequate policy information? • Mobility makes it difficult to have static policy for a single identity – Policy changes based on location – Policy changes based on environment • Large efforts are adding policy negotiation capabilities to IKE for network layer SA s Sepucha_Date_05

  6. Adequate policy information? Adequate policy information? Policy is commonly assumed to flow from a trusted authority • In truth, policy is composed of many local policy authorities • with conditional dominance – This is true for security access control / authorization policy, and for information flow policy. » E.g., an ISP in two different countries have different supported mechanisms. – The Data policy may need to transcend the local policies to find adequate protection services. » E.g., Country X may require an algorithm set that does not meet the protection requirements, the security policy would have to interact with the routing policy to ensure protection. Standards are needed to expand the definition of policy • negotiation. – Coalitions between countries and industry are prime examples. Sepucha_Date_06

  7. Adequate policy information? Adequate policy information? Dominance based policy is being expanded. • – Policy decisions based on a composed policy. » Multiple policy authorities. » Conditional rules based on location and environment. » Turning complete languages? – Lattice based policies are more adaptable to event based information policies. These efforts need additional policy payloads to exchange system • level information. – There is working code and working systems – Need this type of work to filter into the IETF We really can’t keep the one Certificate Authority model for policy • anymore. – Security policies need to be written with a mind toward multiple authorities and mechanisms. Sepucha_Date_07

  8. Are the mechanism flexible enough? Are the mechanism flexible enough? Flexible mechanisms allow us to create standards that stand the • test of time. – Can the standard provide algorithm flexibility? – Does the standard provide hooks for additional services? – What happens when algorithms age? – Intelligent flexibility can enhance performance. » Simple doesn’t always equate to fast » Service modes allow for optimized service modes – TCP MD5 • No key id field: static keying • No service options: one mode • Not authenticated TCP: MD5 – If you need to use something other than MD5 write a standard. • Use of RSA signatures in IPSec ESP and AH may have the same issues. Sepucha_Date_08

  9. What will help? What will help? • The IETF core principles are sound, – Working code and rough consensus. • The group of participants have changed. – Focus on products, not the services that the products provide – Users are absent, mostly. • We need more user based challenges pushing the standards – Work is going on, we need the users to provide input into the standards process. Sepucha_Date_09

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend