IETF
nea
nea@jabber.ietf.org
Wednesday, 28 March 2012< ^ >
Room Configuration

GMT+0
[10:53:40] Alessandro Amirante joins the room
[10:55:44] audiofeed joins the room
[11:02:14] synp joins the room
[11:02:20] <synp> Hi
[11:02:34] <synp> I'm in the room. Begin with MIC: if you want me to channel
[11:02:41] <synp> Meeting begins
[11:02:55] <Alessandro Amirante> Slide 2: Note Well
[11:03:05] sftcd joins the room
[11:03:12] <synp> Steve: could be the last meeting
[11:03:20] <Alessandro Amirante> Slide 3: Agenda Review
[11:03:22] <synp> Agenda bashing
[11:04:10] <synp> NEA reference model
[11:04:27] <synp> slide 6
[11:04:32] <Alessandro Amirante> Slide 5: NEA Reference Model
[11:04:37] <Alessandro Amirante> Slide 6: NEA Reference Model
[11:04:40] <synp> (Steve describes the model)
[11:04:47] <Alessandro Amirante> Slide 7: PA-TNC Within PB-TNC Within PT
[11:04:58] <Alessandro Amirante> Slide 4: WG Status
[11:05:30] <synp> 2nd WGLC run on PT-TLS-02 and PT-EAP-01
[11:05:41] <synp> NEA Asokan attack - we'll hear about it more later
[11:05:48] <Alessandro Amirante> Slide 7: PA-TNC Within PB-TNC Within PT
[11:06:13] <synp> Slide 7 shows the nesting
[11:06:15] <Alessandro Amirante> Slide 8: Use Cases for PT-EAP
[11:06:26] <synp> Use cases for PT-EAP:
[11:06:55] <synp> NEA assessment of 802.1x network to decide about blocking/quarantine
[11:07:13] <synp> NEA assessment for IKEv2 with EAP
[11:07:20] <Alessandro Amirante> Slide 9: Use Cases for PT-TLS
[11:07:25] <synp> Use cases for PT-TLS:
[11:07:44] <synp> 802.1x where the client is already on the network
[11:07:50] <synp> large amount of data
[11:08:00] Susan Thomson joins the room
[11:08:04] <synp> posture re-assessment (after remediation)
[11:08:14] <Alessandro Amirante> Slide 9: Use Cases for PT-TLS
[11:08:15] <synp> doing it in the application layer
[11:08:23] <Alessandro Amirante> Slide 10: PT-TLS Update
[11:08:33] <Alessandro Amirante> Slide 10: PT-TLS Update
[11:08:41] <synp> Now Paul Sangster will present about PT-TLS
[11:09:11] <Alessandro Amirante> Slide 11: Agenda
[11:09:22] <synp> PT-TLS Overview
[11:09:36] Mark Davidson joins the room
[11:09:52] <Alessandro Amirante> Slide 12: PT-TLS Message Format
[11:10:07] <synp> (if you want me to channel something, begin with MIC:)
[11:10:28] <synp> with MIC: )
[11:10:32] <synp> :)
[11:11:17] <Alessandro Amirante> Slide 13: Three Phases of PT-TLS
[11:11:17] <synp> PT-TLS message format. A bunch of TLVs with plenty of code space for the IETF and vendors (32 bit)
[11:11:23] <synp> 3 phases:
[11:11:28] <synp> 1. setup
[11:11:41] <synp> Just TLS handshake
[11:12:10] <synp> 2. PT-TLS Negotiation - version negotiation, optional SASL authentication of NEA client
[11:12:44] <Alessandro Amirante> Slide 14: SASL Client Authentication
[11:14:29] <synp> SASL client authentication: four messages, a MUST requirement to support SASL mechanisms, sent first by the NEA server.
[11:14:49] <synp> MUST support PLAIN and EXTERNAL
[11:15:13] <Alessandro Amirante> Slide 15: PT-TLS -02 Changes
[11:15:15] <Alessandro Amirante> Slide 14: SASL Client Authentication
[11:15:18] <Alessandro Amirante> Slide 16: NEA Server Starts SASL
[11:15:31] <synp> The NEA can start several mechanisms one after the other, but not at the same time
[11:16:08] <synp> Change from -01: Only the NEA server starts SASL. Makes life simpler
[11:16:23] <Alessandro Amirante> Slide 17: Clarifications
[11:18:20] <synp> More changes from -01: clarifications - since the NEA server initiates, the NEA client is a TLS server so uses a X.509 certificate. SHOULD support TLS hearbeat. Renegotiation only during TLS setup
[11:20:16] <synp> Steve Farrel: maybe use TLS server authentication using the mechanism in DANE (as opposed to X.509)
[11:20:44] synp leaves the room
[11:20:52] synp joins the room
[11:20:54] <Alessandro Amirante> Slide 18: Clarifications
[11:21:15] <sftcd> wrt DANE all I meant was "nea wg, please think if you care about DANE" I don't care what conclusion you reach
[11:21:39] <synp> Additional clarifications: NEA client validates certificate based on 5280
[11:21:58] <Alessandro Amirante> Slide 19: WGLC Comments
[11:22:23] cheevarat joins the room
[11:22:35] <synp> WGLC comments: maybe we should mention the other transport (EAP). Paul: agreed.
[11:22:48] <Alessandro Amirante> Slide 20: WGLC Comments
[11:23:47] <Alessandro Amirante> Slide 21: • Section 3.5 PT-TLS Message Format
[11:24:59] <synp> WGLC: change part about copying message identifier to the error message
[11:25:01] <Alessandro Amirante> Slide 22: WGLC Comments
[11:26:02] Lorenzo Miniero joins the room
[11:26:08] <Alessandro Amirante> Slide 23: Questions?
[11:26:14] <synp> WGLC: in section 3.6 change "at another time" to say that that message type (SALS mechanism) should only be sent in NEA setup
[11:26:23] <synp> Questions?
[11:27:00] <synp> Steve: after investigating the DANE issue no need for another WGLC, send it to IESG. Objections?
[11:27:07] <synp> (none heard)
[11:27:14] <synp> Steve: it's cooked, then
[11:28:01] cheevarat leaves the room: Computer went to sleep
[11:28:29] <synp> Susan: If the server does not want authentication, does it still need to send an empty SASL message? Paul: yes. otherwise the client can't continue
[11:28:40] <Alessandro Amirante> Slide 24: PT-EAP Update
[11:28:55] <synp> Now Nancy Cam-Winget will present about PT-EAP Update
[11:28:56] <Alessandro Amirante> Slide 24: PT-EAP Update
[11:29:51] <synp> Nancy: only have two slides
[11:30:09] <Alessandro Amirante> Slide 25: EAP Tunnel Protocol Layers
[11:30:28] <synp> shows diagram of protocol layers
[11:31:05] <synp> designed to be carried over protected tunnel (some tunnel based EAP method)
[11:31:51] <Alessandro Amirante> Slide 26: PT-EAP Message Format
[11:32:31] <synp> The message formats have data length and flags to support fragmentation
[11:32:47] <Alessandro Amirante> Slide 27: Status
[11:32:49] <synp> needs to be cleaned up
[11:33:02] <synp> -01 submitted a few weeks ago.
[11:33:15] <Alessandro Amirante> Slide 28: Remaining Issues
[11:33:19] <synp> Comments addressed with the exception of the following
[11:33:50] <synp> Issue: Move EAP tunnel requirements to "security requirements" rather than "security considerations"
[11:34:56] <sftcd> kathleen stops scribing and justifies her comment:-)
[11:35:31] <synp> Kathlene: It's a result of getting the same comment on one of my documents. There's a new trend for security requirements. People tend to ignore security considerations
[11:36:21] <synp> Nancy: I have no qualms about this. Sec Considerations describes the Asokan attack. The EMEA mitigates this, so I don't care.
[11:36:53] <synp> Steve: let's ask the room. Kathlene: seems you handled it. I'm find with whatever
[11:37:17] <synp> Steve: let's get a sense
[11:37:37] <synp> Some hum to split it, nobody to not split it. The room agrees to split it.
[11:37:52] <Alessandro Amirante> Slide 29: Remaining Issues
[11:38:35] <synp> Issue: Kathleen suggests that we need explicit references to authentication options in 4.3 (for interoperability)
[11:39:05] <synp> Nancy: added parenthetically a mention to EAP-fast and EAP-TTLS. Do we want to reference an upcoming method?
[11:40:19] <synp> Joe Salowey: can't answer, but we have a draft you can reference. Don't know when it will be done. We've had review and moving forward, so not a done deal, but you can reference it and may be done this year. Maybe a non-normative reference.
[11:40:37] <synp> Kathleen: How many are supported tight now?
[11:41:33] <synp> Nancy: we only call out EAP-TLS and TTLS. The language leaves it open-ended.
[11:42:37] <synp> Joe: it's possible to put a reference to EMU's draft. Steve: waiting for guidance from Stephen. Joe: if you do, let EMU know.
[11:43:30] <synp> Mike Boyle: If EMU was available, would it be mandatory? Nancy: based on consensus Mike: it makes sense to have a mandatory to implement Steve: we're not delaying this waiting for EMU's method
[11:44:00] <synp> Joe: can also see how the pacing turns out to be. Steve: if they catch up, good.
[11:44:43] <synp> Stephen: Why not any mandatory now? Nancy: all methods are informational
[11:45:46] <synp> Stephen: downref is OK Steve: we don't want to push people backwards. Nancy: standardized is better, so we did not make mandatory informational ones. Stephen: so "we would if EMU was done" is OK.
[11:46:32] <synp> Stephen: they would pick EMU's if it was finished. add a reference to the document (informative) and make in normative if it gets finished.
[11:46:54] <synp> Stephen: is it possible that when finished it won't be suitable? Joe: no
[11:47:08] <synp> Stephen: so use an informative reference.
[11:47:17] <synp> Nancy: that's it for the issues.
[11:47:22] <Alessandro Amirante> Slide 30: Comments on -01 by Steve Hanna
[11:47:34] <Alessandro Amirante> Slide 29: Remaining Issues
[11:47:51] <Alessandro Amirante> Slide 30: Comments on -01 by Steve Hanna
[11:47:53] <Alessandro Amirante> Slide 31: Comments on -01 by Steve Hanna
[11:47:54] <Alessandro Amirante> Slide 32: Comments on -01 by Carolin Latze
[11:47:55] <Alessandro Amirante> Slide 33: -01 Received Comments Resolutions
[11:47:57] <synp> Removed the need for fragmentation as the tunnel method will have that
[11:48:07] <Alessandro Amirante> Slide 32: Comments on -01 by Carolin Latze
[11:48:08] <Alessandro Amirante> Slide 31: Comments on -01 by Steve Hanna
[11:48:10] <Alessandro Amirante> Slide 30: Comments on -01 by Steve Hanna
[11:48:17] <synp> Comments on -01:
[11:49:27] <sftcd> @synp: nicely captured discussion wrt EMU:-)
[11:50:18] <synp> From Steve Hanna: nits, remove bits related to fragmentation from message format, cleaning up language
[11:50:19] <Alessandro Amirante> Slide 31: Comments on -01 by Steve Hanna
[11:50:38] <Alessandro Amirante> Slide 32: Comments on -01 by Carolin Latze
[11:52:39] Dan York joins the room
[11:52:41] <synp> From Carolin Latze: nits, in section 3.4 channel binding solution is only for TLS, but previous sections say "TLS or something with comparable features". Maybe we need to re-iterate the requirement that it be TLS-based (in section 2 as well)
[11:52:49] <Alessandro Amirante> Slide 33: -01 Received Comments Resolutions
[11:53:02] <synp> Steve: agrees. Any other questions or comments?
[11:53:05] <synp> (none)
[11:53:15] <Alessandro Amirante> Slide 43: NEA Asokan Attack Analysis
[11:53:23] <synp> Joe Salowey will present the "NEA Asokan Attack Analysis"
[11:53:25] <Alessandro Amirante> Slide 43: NEA Asokan Attack Analysis
[11:53:34] <Alessandro Amirante> Slide 44: Asokan Attack on NEA
[11:53:59] <synp> (reminds us what the Asokan attack is)
[11:55:39] <Alessandro Amirante> Slide 45: External Measurement Agent
[11:56:03] <Alessandro Amirante> Slide 46: TLS-Unique Channel Binding
[11:56:44] <synp> TLS-Unique channel binding defined in RFC 5929 binds to EMA exchange
[11:57:20] <synp> Finished detects the MitM
[11:57:21] <Alessandro Amirante> Slide 47: Changes from -00 to -01
[11:57:53] <synp> in version -01: updated references. reflected decision to use tls-unique channel binding
[11:59:16] Dan York leaves the room
[12:00:09] <synp> Hao Zhou: what are the requirements from the TLS methods? Jow: pass the channel binding to the PT-EAP
[12:01:59] <synp> Nancy: in PT-EAP security considerations we put a normative reference. In the presence of an MEA you need tls_unique. What more? Hao: text is not clear, say you need to bind tls_uniq to PT-EAP. EAP-FAST and TTLS don't do it now.
[12:02:17] <synp> Joe: correct, but this is an implementation detail. They should
[12:02:24] <Alessandro Amirante> Slide 48: Next Steps
[12:02:35] <synp> Joe: would like this to be adopted and go quickly to WGLC
[12:02:52] <synp> Steve: let's check consensus. Any more discussion?
[12:03:16] <synp> about 7 have read it (8 including the author)
[12:03:29] <synp> Would you like to adopt it: strong hum
[12:03:34] <synp> Against: silence
[12:03:49] <Alessandro Amirante> Slide 49: NEA WG Next Steps
[12:03:51] <synp> Steve: pretty clear. Confirm on the list, and the AD is OK with it.
[12:04:13] <Alessandro Amirante> Slide 49: NEA WG Next Steps
[12:04:14] <Alessandro Amirante> Slide 50: Next Steps
[12:04:24] <synp> Steve: next steps
[12:05:02] <Alessandro Amirante> Slide 51: Milestones
[12:05:32] <synp> In April: -03 of PT-TLS, -02 of PT-EAP, -00 on Asokan attack.
[12:06:09] <synp> May: send PT-EAP and Asokan to IESG. By the end of May, all three will be with IESG and going through IETF LC.
[12:06:18] <synp> If nothing bad happens, won't meet again?
[12:06:21] <synp> Anything more?
[12:06:24] <Alessandro Amirante> Slide 52: Adjourn
[12:06:25] <synp> Thank you.
[12:06:28] <synp> Adjourned
[12:06:30] <Alessandro Amirante> Presentation stopped
[12:06:30] sftcd leaves the room
[12:06:31] synp leaves the room
[12:06:38] Alessandro Amirante leaves the room
[12:07:09] audiofeed leaves the room
[12:07:44] Lorenzo Miniero leaves the room
[12:08:45] Susan Thomson leaves the room
[12:09:00] Mark Davidson leaves the room
[12:42:39] Gonzalo joins the room
[12:43:02] Danny Haynes joins the room
[12:43:39] Gonzalo leaves the room
[12:44:34] Danny Haynes leaves the room