1 / 30

NEA Working Group IETF meeting Nov 8, 2010

NEA Working Group IETF meeting Nov 8, 2010. nea [-request]@ ietf.org http://tools.ietf.org/wg/nea Co-chairs: Steve Hanna shanna@juniper.net Susan Thomson sethomso@cisco.com. Note Well.

elaine-key
Download Presentation

NEA Working Group IETF meeting Nov 8, 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. NEA Working GroupIETF meetingNov 8, 2010 nea[-request]@ietf.org http://tools.ietf.org/wg/nea Co-chairs: Steve Hanna shanna@juniper.net Susan Thomson sethomso@cisco.com IETF NEA Meeting

  2. Note Well Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: • The IETF plenary session • The IESG, or any member thereof on behalf of the IESG • Any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices • Any IETF working group or portion thereof • The IAB or any member thereof on behalf of the IAB • The RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 5378 and RFC 3979 (updated by RFC 4879). Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 5378 and RFC 3979 for details. A participant in any IETF activity is deemed to accept all IETF rules of process, as documented in Best Current Practices RFCs and IESG Statements. A participant in any IETF activity acknowledges that written, audio and video records of meetings may be made and may be available to the public. IETF NEA Meeting

  3. Agenda Review 1300 Administrivia Jabber & Minute scribes Agenda bashing 1305 WG Status 1310 NEA Reference Model 1315 NEA Asokan Design Team Report http://www.ietf.org/internet-drafts/draft-salowey-nea-asokan-00.txt 1415 Consensus Question 1430 Health Certificates http://www.ietf.org/internet-drafts/draft-chen-pkix-securityinfo-00.txt 1450 Next Steps 1455 Milestones 1500 Adjourn IETF NEA Meeting

  4. WG Status • PT protocols under consideration • WG consensus to address NEA Asokan attack (IETF 78) • Design team formed (Aug 2010) • Report from design team published (Oct 2010) http://www.ietf.org/internet-drafts/draft-salowey-nea-asokan-00.txt IETF NEA Meeting

  5. NEA Reference Model IETF NEA Meeting

  6. NEA Reference Modelfrom RFC 5209 NEA Client NEA Server Posture Attribute (PA) protocol Posture Collectors Posture Validators Posture Broker (PB) protocol Posture Broker Client Posture Broker Server Posture Transport Client Posture Transport Server Posture Transport (PT) protocols IETF NEA Meeting

  7. PA-TNC Within PB-TNC Within PT PT PB-TNC Header PB-TNC Message (Type=PB-Batch-Type, Batch-Type=CDATA) PB-TNC Message (Type=PB-PA, PA Vendor ID=0, PA Subtype= OS) PA-TNC Message PA-TNC Attribute (Type=Product Info, Product ID=Windows XP) PA-TNC Attribute (Type=Numeric Version, Major=5, Minor=3, ...) IETF NEA Meeting

  8. NEA Asokan Attack Mitigation Design Team Nancy Cam-Winget Steve Hanna Joe Salowey Paul Sangster IETF NEA Meeting

  9. Design Team • Met several times since last IETF • Captured discussion in ID • draft-salowey-nea-asokan-00 • Provides overview of the Attack • Suggests Mitigations IETF NEA Meeting

  10. Asokan Attack Reference: http://www.ietf.org/mail-archive/web/nea/current/pdf7WUdfx5UDq.pdf Attack characteristics: Requires a Spy AP, Spy Server, Spy Laptop Corp Laptop must already have a good connection to CorpServer Corp Laptop must have bad code in order to forward traffic to Spy Server (pg. 3, 3rd paragraph of Mounting an Asokan Attack on NEA section) IETF NEA Meeting

  11. Asokan Attack on NEA • Preconditions • NEA Assessment • CorpLaptop Infection • Lying Endpoint Detection (PA Trust Model) • SpyLaptop configured to allow communication with untrustworthy SpyServer(PT Trust Model) • PA Forwarding attack ! CorpUser CorpLaptop CorpServer SpyUser SpyLaptop SpyServer IETF NEA Meeting

  12. External Measurement Agent • The “Asokan Attack” is most significant when there is an independent entity that can collect and authenticate the assessments • The draft refers to this entity as an “external measurement agent” or EMA • If the tunnel and EMA authentication are not bound together then the system is vulnerable to the “Asokan Attack” IETF NEA Meeting

  13. Solution Properties • Bind TLS connection to EMA authenticated data to ensure that the EMA and TLS endpoints are the same or trust each other • Have a mechanism that can be used in L2 and L3 transports IETF NEA Meeting

  14. Commonly used TLS establishment NEA Client NEA Server Hello Request (optional) M1: Client Hello (client_random, TLS_RSA_WITH_XXX) • M2: Server Hello ( server_random, SID, TLS_RSA_WITH_XXX) • Server Certificate • Server Hello Done [marks end of ServerHello] M3a: ClientKeyExchange( ENC[pre_master_secret] ) M3b: ChangeCipherSpec M3c: ENC[ Finished( PRF(master_secret, “client_finished”, hash(M1 || M2 || M3a || M3b))] M3 M4a: ChangeCipherSpec M4b: Finished[ PRF(master_secret, “server_finished”, hash(M1 || M2 || M3 || M4a))] master_secret = f(pre_master_secret, client_random, server_random) IETF NEA Meeting

  15. Solution Proposals • Bind data from TLS exchange into EMA exchange • Assume EMA can provide source authentication for data • Three Approaches • TLS Identity • TLS key exporter • TLS-unique Channel binding IETF NEA Meeting

  16. TLS Identity • Bind identities exchanged in the TLS handshake in the EMA exchange • Difficult because identity is different for different cipher suites • Does not bind to a particular TLS connection IETF NEA Meeting

  17. TLS Keying Material Export • Export key material using RFC 5705 • Binds exchange to particular connection • Key material depends entirely upon TLS master secret • Secret cannot be solely determined by client or server • Diffie-Hellman key agreement based cipher suites must be used • Approach originally taken in draft • To be revised IETF NEA Meeting

  18. TLS-Unique Channel Binding • Uses tls-unique Channel Binding defined in RFC 5929 to bind into EMA exchange • tls-unique is the contents of the first Finished message • Finished( PRF(master_secret, “client_finished”, hash(M1 || M2 || M3a || M3b)) • Binds to a particular TLS connection • Can be used with any cipher suite IETF NEA Meeting

  19. M1: ClientHello M1: ClientHello NEA Server MitM M2: ServerHello( nea_server_cert) M2”: ServerHello (MitM_cert) NEA Client Asokan Mitigation through Channel Bind M3: Finished ( hash[M1 || M2] ) M3”: Finished ( hash[M1 || M2”] ) ch_bind = hash( M3 ) ch_bind” = M3” PA conversation must apply channel bind to confirm no MitM e.g. EMA takes ch_bind and executes a PA layer exchange to prove knowledge of the same ch_bind in a (integrity and replay) protected exchange. IETF NEA Meeting

  20. Recommendation • tls-unique is the way to go • TLS exporter has additional constraints and is redundant to tls-unique IETF NEA Meeting

  21. Consensus Check Question • Agree with recommended approach to mitigating NEA Asokan attack? • Yes • No • Don’t know IETF NEA Meeting

  22. X.509 extension with security information draft-chen-pkix-securityinfo-00 IETF 79 chen.shuyi@zte.com.cn viviytliu@gmail.com IETF NEA Meeting

  23. draft-chen-pkix-securityinfo-00.txt • Security problems related to distributed network seldom take bad influence caused by underlay into consideration. Nodes with weak protection in underlay will greatly deteriorate security of the distributed network. • We want to make overlay cognize the security posture for underlay in a scalable and practical way. -This X.509 certificate extension keeps underlay security information of the subject. - Based on this certificate, one entity or node can cognize another's security posture, then adjusts strategy to avoid attacks from malicious entities. IETF NEA Meeting

  24. Assessment Elements SecurityData ::=SEQUENCE{ antivirus [0] AntivirusData， firewall [1] FirewallData， operatingSystem [2] OSData， vulnerabilityDatabase [3] VDData, maliciousPlug-in [4] MPIData, otherSecData [5...MAX] ANY defined security data, OPTIONAL } AntivirusData ::= SEQUENCE { antivirusBase BasicInfo, otherAntivirusData ANY defined AntivirusData OPTIONAL } BasicInfo ::= SEQUENCE { version IA5String, manufacturer IA5String, renewal BOOLEAN } IETF NEA Meeting

  25. Assessment Elements FirewallData ::= SEQUENCE { firewallBase BasicInfo, supFTPFileFilter BOOLEAN, supAntivirus BOOLEAN, supConFilter BOOLEAN, defDOS BOOLEAN, rtInRes BOOLEAN, autoLogScan BOOLEAN, otherFirewallData ANY defined FirewallData OPTIONAL} OSData ::= INTEGER (because OS data is private) VDData ::= BOOLEAN MPIData ::= SEQUENCE { malPlugIn ANY defined malicious Plug-In } IETF NEA Meeting

  26. Comments PKIX WG • Why not attribute certificate or short life health identity certificate -posture frequently changes/update mechanism implementation of PKI/PMI -subject directory attribute extension-update problem • Verify - third trusted party - proxy certificate IETF NEA Meeting

  27. Discussion NEA WG • Assertion Attributes / Posture Attributes -endpoint posture :IETF standard subtypes -relationship with security information? • Way to go IETF NEA Meeting

  28. Proposed NEA WG Next Steps • Revise PT protocol I-Ds to include Asokan mitigation • Create a separate draft for EMA implementor guidance (informational) IETF NEA Meeting

  29. Milestones Done Set up design team to work on PT extension I-D Done Output of Design team due Jan 2011 Revise PT I-Ds Jan 2011 Resolve PT I-Ds at Virtual interim meeting Feb 2011 Publish -00 NEA WG PT I-Ds Mar 2011 Resolve issues with -00 NEA WG PT I-Ds at IETF 80 Apr 2011 Publish -01 NEA WG PT I-Ds May 2011 WGLC on -01 NEA WG PT I-Ds Jun 2011 Publish -02 NEA WG PT I-Ds Jun 2011 IETF LC Jul 2011 Resolve issues from IETF LC at IETF 81 Aug 2011 Send -03 NEA WG PT I-Ds to IESG IETF NEA Meeting

  30. Adjourn IETF NEA Meeting

More Related