nea working group ietf meeting nov 8, 2010
DESCRIPTION
NEA Working Group IETF meeting Nov 8, 2010. nea [-request]@ ietf.org http://tools.ietf.org/wg/nea Co-chairs: Steve Hanna [email protected] Susan Thomson [email protected]. Note Well. - PowerPoint PPT PresentationTRANSCRIPT
NEA Working GroupIETF meetingNov 8, 2010
nea[-request]@ietf.orghttp://tools.ietf.org/wg/nea
Co-chairs: Steve Hanna [email protected] Susan Thomson [email protected]
Nov 8, 2010 IETF NEA Meeting 1
IETF NEA Meeting 2
Note WellAny 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.
Nov 8, 2010
Agenda Review1300 Administrivia
Jabber & Minute scribesAgenda bashing
1305 WG Status1310 NEA Reference Model1315 NEA Asokan Design Team Report http://www.ietf.org/internet-drafts/draft-salowey-nea-asokan-00.txt1415 Consensus Question 1430 Health Certificates http://www.ietf.org/internet-drafts/draft-chen-pkix-securityinfo-00.txt1450 Next Steps1455 Milestones1500 Adjourn
Nov 8, 2010 IETF NEA Meeting 3
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, 2010 IETF NEA Meeting 4
NEA Reference Model
Nov 8, 2010 IETF NEA Meeting 5
NEA Reference Modelfrom RFC 5209
Posture Collectors
Posture Validators
PostureTransportServer
Posture Attribute (PA) protocol
Posture Broker (PB) protocol
NEA Client NEA Server
Posture Transport (PT) protocolsPostureTransportClient
PostureBrokerClient
PostureBrokerServer
Nov 8, 2010 6IETF NEA Meeting
PA-TNC Within PB-TNC Within PTPT
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, 2010 7IETF NEA Meeting
NEA Asokan Attack Mitigation Design Team
Nancy Cam-WingetSteve HannaJoe Salowey
Paul Sangster
Nov 8, 2010 8IETF NEA Meeting
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, 2010 9IETF NEA Meeting
Nov 8, 2010 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
SpyLaptopSpyUser
Asokan Attack on NEA
Nov 8, 2010 11
Preconditions1. NEA Assessment2. CorpLaptop Infection3. Lying Endpoint Detection
(PA Trust Model)4. SpyLaptop configured to allow
communication with untrustworthy SpyServer (PT Trust Model)
5. PA Forwarding attack
CorpLaptop CorpServerCorpUser
N !
SpyServer
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, 2010 12IETF NEA Meeting
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, 2010 13IETF NEA Meeting
Commonly used TLS establishment
NEAServer
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 CertificateServer Hello Done [marks end of ServerHello]
M3a: ClientKeyExchange( ENC[pre_master_secret] )M3b: ChangeCipherSpecM3c: ENC[ Finished( PRF(master_secret, “client_finished”, hash(M1 || M2 || M3a || M3b))]
master_secret = f(pre_master_secret, client_random, server_random)
M4a: ChangeCipherSpecM4b: Finished[ PRF(master_secret, “server_finished”, hash(M1 || M2 || M3 || M4a))]
M3
Nov 8, 2010 14IETF NEA Meeting
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, 2010 15IETF NEA Meeting
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, 2010 16IETF NEA Meeting
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, 2010 17IETF NEA Meeting
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 suiteNov 8, 2010 18IETF NEA Meeting
Asokan Mitigation through Channel Bind
NEA ServerNEA 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 MitMe.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, 2010 19IETF NEA Meeting
Recommendation
• tls-unique is the way to go• TLS exporter has additional constraints
and is redundant to tls-unique
Nov 8, 2010 20IETF NEA Meeting
Consensus Check Question
• Agree with recommended approach to mitigating NEA Asokan attack?– Yes– No– Don’t know
Nov 8, 2010 IETF NEA Meeting 21
X.509 extension with security information
draft-chen-pkix-securityinfo-00IETF 79
[email protected]@gmail.com
Nov 8, 2010 22IETF NEA Meeting
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, 2010 23IETF NEA Meeting
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, 2010 24IETF NEA Meeting
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, 2010 25IETF NEA Meeting
CommentsPKIX 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, 2010 26IETF NEA Meeting
NEA WG• Assertion Attributes / Posture Attributes -endpoint posture :IETF standard subtypes -relationship with security information?• Way to go
Discussion
Nov 8, 2010 27IETF NEA Meeting
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, 2010 IETF NEA Meeting 28
MilestonesDone Set up design team to work on PT extension I-DDone Output of Design team dueJan 2011 Revise PT I-DsJan 2011 Resolve PT I-Ds at Virtual interim meetingFeb 2011 Publish -00 NEA WG PT I-DsMar 2011 Resolve issues with -00 NEA WG PT I-Ds at IETF 80Apr 2011 Publish -01 NEA WG PT I-DsMay 2011 WGLC on -01 NEA WG PT I-DsJun 2011 Publish -02 NEA WG PT I-DsJun 2011 IETF LCJul 2011 Resolve issues from IETF LC at IETF 81Aug 2011 Send -03 NEA WG PT I-Ds to IESG
Nov 8, 2010 IETF NEA Meeting 29
IETF NEA Meeting 30
Adjourn
Nov 8, 2010