NEA Working Group IETF meeting Nov 8, 2010

NEA Working GroupIETF meetingNov 8, 2010

nea[-request]@ietf.org

http://tools.ietf.org/wg/nea

Co-chairs: Steve Hanna [email protected]

Susan Thomson [email protected]

Nov 8, 2010 IETF NEA Meeting 1

mailto:[email protected]

mailto:[email protected]

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

http://www.ietf.org/rfc/rfc5378.txt





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.txt

1415 Consensus Question

1430 Health Certificates

http://www.ietf.org/internet-drafts/draft-chen-pkix-securityinfo-00.txt1450 Next Steps1455 Milestones1500 Adjourn



http://www.ietf.org/internet-drafts/draft-chen-pkix-securityinfo-00.txt

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)





NEA Reference Model


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 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, ...)


NEA Asokan Attack Mitigation Design Team

Nancy Cam-Winget

Steve Hanna

Joe Salowey

Paul Sangster


Design Team

• Met several times since last IETF• Captured discussion in ID

– draft-salowey-nea-asokan-00– Provides overview of the Attack– Suggests Mitigations



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)

http://www.ietf.org/mail-archive/web/nea/current/pdf7WUdfx5UDq.pdf

http://www.ietf.org/mail-archive/web/nea/current/pdf7WUdfx5UDq.pdf

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”


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


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


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


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


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 revisedNov 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.


Recommendation

• tls-unique is the way to go• TLS exporter has additional constraints

and is redundant to tls-unique


Consensus Check Question

• Agree with recommended approach to mitigating NEA Asokan attack?– Yes– No– Don’t know


X.509 extension with security information

draft-chen-pkix-securityinfo-00IETF 79

[email protected]

[email protected]


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.


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 }


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 }


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


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

Discussion


Proposed NEA WG Next Steps

• Revise PT protocol I-Ds to include Asokan mitigation

• Create a separate draft for EMA implementor guidance (informational)


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

Nov 8, 2010

NEA Working Group IETF meeting Nov 8, 2010

Documents

Transcript of NEA Working Group IETF meeting Nov 8, 2010