1. NEA Working Group IETF meeting Nov 8, 2010 nea[-request]@ietf.org http://tools.ietf.org/wg/nea Co-chairs: Steve Hanna shanna@juniper.netshanna@juniper.net Susan Thomsonsethomso@cisco.comsethomso@cisco.com Nov 8, 2010IETF NEA Meeting1

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).RFC 5378RFC 3979RFC 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.RFC 5378RFC 3979 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. Nov 8, 20102IETF 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 Nov 8, 2010IETF NEA Meeting3

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 Nov 8, 2010IETF NEA Meeting4

5. NEA Reference Model Nov 8, 2010IETF NEA Meeting5

6. NEA Reference Model from RFC 5209 Posture Collectors Posture Validators Posture Transport Server Posture Attribute (PA) protocol Posture Broker (PB) protocol NEA ClientNEA Server Posture Transport (PT) protocols Posture Transport Client Posture Broker Client Posture Broker Server Nov 8, 20106IETF 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,...) Nov 8, 20107IETF NEA Meeting

8. NEA Asokan Attack Mitigation Design Team Nancy Cam-Winget Steve Hanna Joe Salowey Paul Sangster Nov 8, 20108IETF 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 Nov 8, 20109IETF NEA Meeting

10. Nov 8, 2010IETF NEA Meeting10 Asokan Attack Reference: http://www.ietf.org/mail- archive/web/nea/current/pdf7WUdfx5UDq.pdfhttp://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, 3 rd paragraph of Mounting an Asokan Attack on NEA section)

11. SpyLaptop SpyUser Asokan Attack on NEA Nov 8, 2010IETF NEA Meeting11 Preconditions 1.NEA Assessment 2.CorpLaptop Infection 3.Lying Endpoint Detection (PA Trust Model) 4.SpyLaptop configured to allow communication with untrustworthy SpyServer (PT Trust Model) 5.PA Forwarding attack CorpLaptopCorpServer CorpUser ! SpyServer

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” Nov 8, 201012IETF 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 Nov 8, 201013IETF NEA Meeting

14. Commonly used TLS establishment NEA Server NEA Client 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 ))] master_secret = f(pre_master_secret, client_random, server_random) M4a: ChangeCipherSpec M4b: Finished[ PRF( master_secret, “server_finished”, hash(M1 || M2 || M3 || M4a ))] M3 Nov 8, 201014IETF 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 Nov 8, 201015IETF 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 Nov 8, 201016IETF 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 Nov 8, 201017IETF 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 Nov 8, 201018IETF NEA Meeting

19. Asokan Mitigation through Channel Bind NEA Server NEA Client MitM M1: ClientHello M2”: ServerHello (MitM_cert) M1: ClientHello M2: ServerHello( nea_server_cert) M3”: Finished ( hash[M1 || M2”] ) M3: Finished ( hash[M1 || M2] ) ch_bind” = M3” ch_bind = hash( 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. Nov 8, 201019IETF NEA Meeting

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

21. Consensus Check Question Agree with recommended approach to mitigating NEA Asokan attack? –Yes –No –Don’t know Nov 8, 2010IETF NEA Meeting21

22. X.509 extension with security information draft-chen-pkix-securityinfo-00 IETF 79 chen.shuyi@zte.com.cn viviytliu@gmail.com Nov 8, 201022IETF 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. Nov 8, 201023IETF 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 } BasicInfo ::= SEQUENCE { version IA5String, manufacturer IA5String, renewal BOOLEAN } AntivirusData ::= SEQUENCE { antivirusBase BasicInfo, otherAntivirusData ANY defined AntivirusData OPTIONAL } Nov 8, 201024IETF NEA Meeting

25. FirewallData ::= SEQUENCE { firewallBase BasicInfo, supFTPFileFilter BOOLEAN, supAntivirus BOOLEAN, supConFilter BOOLEAN, defDOS BOOLEAN, rtInRes BOOLEAN, autoLogScan BOOLEAN, otherFirewallData ANY defined FirewallData OPTIONAL} Assessment Elements OSData ::= INTEGER (because OS data is private) VDData ::= BOOLEAN MPIData ::= SEQUENCE { malPlugIn ANY defined malicious Plug-In } Nov 8, 201025IETF 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 Nov 8, 201026IETF NEA Meeting

27. NEA WG Assertion Attributes / Posture Attributes -endpoint posture :IETF standard subtypes -relationship with security information? Way to go Discussion Nov 8, 201027IETF 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) Nov 8, 2010IETF NEA Meeting28

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

30. Adjourn Nov 8, 201030IETF NEA Meeting