Subject: [Nea] Draft ITF79 NEA WG meeting minutes

From: "Susan Thomson (sethomso)" <[email-masked]>
Date: Sun, 12 Dec 2010 19:57:34 -0600

Below are draft minutes for the NEA WG at IETF79.

Please send corrections to me by Friday 17 Dec 2010.

Thanks
Susan
--------------------------------------------------

These notes do not attempt to duplicate the content of the slides. 
Instead, they summarize the material presented, and focus on 
comments and discussion.

Agenda
======

Date: Monday, Nov 8, 2010
Time: 1300-1500 
WG Charter: http://www.ietf.org/html.charters/nea-charter.html
WG Tools: http://tools.ietf.org/wg/nea
WG email: [email-masked]

1300 Administrivia
         Blue Sheets
         Jabber & Minute scribes
         Agenda bashing
1305 WG Status
1310 NEA Reference Model
1315 NEA Asokan Design Team Report 
     draft-salowey-nea-asokan-00.txt
1415 Consensus Question
1430 Health Certificates
     draft-chen-pkix-securityinfo-00.txt
1450 Next Steps
1455 Milestones
1500 Adjourn

WG Status
=========
Susan Thomson reviewed WG status. A design team was formed in 
August 2010 to recommend an approach to mitigating the NEA Asokan 
attack. The main objective of this meeting is to review the design 
team's recommendation and check WG consensus for that 
recommendation. 

NEA Reference Model
====================
Steve Hanna reviewed the NEA reference model for the benefit of 
those new to the WG.

NEA Asokan Attack
=================
Joe Salowey reported that the design team had met several times 
since the last meeting and published an overview of the NEA Asokan 
attack and possible mitigations in an I-D (draft-salowey-nea-
asokan-00.txt). 

Joe Salowey reviewed the NEA Asokan attack (see 
http://www.ietf.org/mail-archive/web/nea/current/msg01080.html). 

Briefly, a compromised NEA client establishes a secure transport 
connection with a NEA server. The objective of the attacker is to 
have the compromised endpoint appear to be compliant to the NEA 
server. This can be accomplished by having a spy machine, which is 
compliant, send its posture to a spy NEA server, which in turn 
forwards the PA and PB posture attributes via the compromised NEA 
client to the NEA server. Without any counter-measures, the NEA 
server is unable to detect that the posture is not that of the 
compromised machine.

Joe asked whether there were any clarifying questions regarding 
the nature of the Asokan attack.

Ke Tang asked whether the spy machine needs to be a valid machine.

Joe responded that the important point is that the spy machine 
needs to have valid posture. 

Ke Tang asked whether the spy user can control the spy server 
completely.

Joe responded in the affirmative. The spy machine and spy server 
together are taking advantage of the compromised NEA client to 
forward posture from the spy machine to the NEA server.

The NEA Asokan attack is most effective when the compromised 
machine has technology that can sign NEA assessments so that the 
NEA Server can authenticate the posture information. The design 
team refers to such technology as an External Measurement Agent 
(EMA). The NEA Asokan attack is possible when the EMA is not bound 
to the Posture Transport.

The main properties of the solution are the following:
- Bind the Posture Transport to the EMA 
- Must work over L2 and L3 Posture Transports

Joe reviewed 3 possible solutions:
1. TLS Identity
2. TLS Exporter
3. TLS-unique Channel Binding

The TLS Identity proposal binds the identities exchanged in the 
TLS handshake to the EMA exchange. The disadvantage of this 
approach is that identity is defined differently in different 
ciphersuites, and the exchange is not bound to a specific TLS 
connection.

The TLS Exporter exports key material using RFC 5705. This 
proposal has the property that it binds the EMA exchange to a 
specific connection. However, it requires that Diffie-Hellman 
ciphersuites be used because the key material cannot be determined 
solely from client or server. This is the approach recommended in 
the I-D (draft-salowey-nea-asokan-00.txt), but subsequent to 
publishing the I-D, the design team came up with a better 
approach.

The third proposal uses the tls-unique Channel Binding defined in 
RFC 5929, where tls-unique is the contents of the first Finished 
message in a TLS handshake. The tls-unique Channel Binding has the 
property that it is specific to a TLS connection, and can be used 
with any ciphersuite.

The recommendation of the design team is to use tls-unique channel 
binding. It has been reviewed with Niko Williams who is a co-
author of RFC 5929.

Consensus Check Question:
=========================
Susan asked whether the WG agreed with the recommended approach of 
using the tls-unique Channel Binding.

The result was unanimous in favor of adopting the recommendation.

This result needs to be confirmed on the list.

Health Certificates:
====================
Yuting Liu described an individual submission (draft-chen-pkix-
securityinfo-00.txt) where posture attributes are included in a 
X.509 certificate extension between communicating entities. The 
posture attributes defined in the draft are not consistent with 
the NEA RFCs.

Yuting Liu opened the floor for discussion on the relationship to 
the NEA WG and next steps.

Ke Tang asked a question about the relationship between assertion 
attributes and posture attributes as defined in NEA.

Steve said that posture attributes carry information about the 
security configuration of a machine such as the name and version 
of the anti-virus software the machine is running. Assertion 
attributes are declarations about the results of a previous 
compliance check. 

Steve raised privacy and security issues in the certificate 
extension proposal that arise when disclosing too much information 
about the endpoint. This is one reason why it may be better to 
carry the posture result rather than all of the details.

Yuting Liu agreed that this should be considered.

Steve suggested that the authors should look at the Microsoft 
health certificate, which is similar in concept.

Steve asked whether an analysis had been done on the differences 
in the approach taken between using certificates and an online 
assessment. He suggested that one advantage of the certificate 
extension is that it can be used with existing protocols that make 
use of certificates.

Nancy raised a concern about updating identity certificates and 
their revocation due to posture changes. 

Yuting Liu responded that this is being taken under consideration, 
possibly using short-lived identity certificates, or attribute 
certificates.

Steve said that a good use case for certificates is the wireless 
roaming case where the efficiency of posture re-assessments is a 
concern.

Tim Polk addressed the issue of next steps for the I-D. He says he 
is not in favor of expanding the NEA WG milestones to include 
health certificates at this time. He would like to see more work 
done on the proposal, and broader community interest behind it. He 
also agrees that existing solutions in this space should be 
investigated.

Proposed Next Steps:
====================
Susan reviewed next steps: 
- The PT proposals will be updated to include Asokan mitigation 
(subject to a consensus check on the mailing list)
- Separate I-D for guidance to EMA implementers (informational)

Proposed Milestones:
====================
Susan reviewed the updated milestones. The goal is to hold a 
virtual interim meeting in January to converge on the PT 
protocols, and have the -00 version of the NEA WG ready for review 
at IETF80. 

Meeting adjourned.