These notes do not attempt to duplicate the content of the slides. Instead, they summarize the material presented, and focus on comments and discussion. Notes taken by Chris Inacio. Agenda ====== Date: Thursday, Nov 17, 2011 Time: 0900-1130 WG Charter: http://www.ietf.org/html.charters/nea-charter.html WG Tools: http://tools.ietf.org/wg/nea WG email: nea@ietf.org 0900 Administrivia Jabber & Minute scribes Agenda bashing 0905 WG Status 0910 NEA Reference Model 0915 Discuss and Resolve Open WGLC PT-TLS Comments draft-ietf-nea-pt-tls-01.txt 1000 Discuss and Resolve PT_EAP Issues draft-ietf-nea-pt-eap-00.txt 1100 Discuss next steps for NEA Asokan I-D 1115 Discuss Next Steps 1130 Adjourn WG Status ========= Susan Thomson reviewed WG status. Since the last IETF, PT-TLS I-D has gone through WGLC. Several issues have been raised which will be discussed in the meeting today. PT-EAP was published as a WG document. Some comments have been received, but more are needed. Discuss and Resolve WGLC PT-TLS Comments ======================================== Joe Salowey went through the list of issues that had been brought up on the mailing list in response to WGLC. Issues include: 1)TLS Keepalive 2)Version Negotiation 3)SASL Negotiation 4)PT Client as TLS Server 5)Channel Bindings 1) TLS Keepalive To address the issue of how to keep the TLS session up, the proposal is to use the TLS heartbeat mechanism described in draft-ietf-tls- dtls-heartbeat. This draft is going through the IESG now, and should be an RFC prior to the PT-TLS being published. The keepalive mechanism would be optional to implement. Stephen Farrell raised the question of whether it should be optional to implement for both sides. Steve Hanna said it could be mandatory to implement at the NEA server. Joe asked for clarification of the use case. Steve said that the use case would be that the TLS session needs to be kept up to allow the NEA server to revalidate the client after some period, which may leave a long time during which the TLS session is not carrying traffic. Nancy Cam-Winget asked for clarification on the need to implement the TLS server on the NEA client. Steve says that he is pretty sure that the draft does not require that NEA clients need to implement the TLS Server. Nancy says that this should be made clear in the draft. Joe summarized by saying that the draft currently allows the NEA server to be a TLS server or a TLS Client. If we made keepalives mandatory to implement on the NEA server, this would enable the NEA server to revalidate the client without having to start a new TLS session (assuming the client supported it). Joe continued that the keepalive capability is negotiated at the TLS layer, so if the client did not support this, there would be a degradation of service, not a hard failure. Joe said that the editors would get together to think through the ramifications of making this optional versus mandatory and make a proposal to the list. 2) Version Negotiation Regarding version negotiation, the draft says the following: “Subsequent assessments on the same session MUST use the negotiated version number and therefore SHOULD NOT send additional version negotiation messages.” The proposal is to change the SHOULD NOT to a MUST NOT. Steve said that there is no point in allowing further version negotiation given that the protocol forbids a different version to be used during a session. Joe says we would need to check that the draft handles the error case. Alexey asked whether this discussion was referring to TLS version negotiation. Joe clarified it was PT-TLS. There were no objections to making this change. 3)SASL Initiation Currently, the draft allows for both the SASL client and server to initiate the SASL exchange. This leads to some additional complexity in the protocol, and the draft is not clear on the behavior in all cases. One proposal would be to have the TLS server always initiate the SASL exchange since it has the policy determining whether the client needs to be authenticated. The client would not have a way to initiate the exchange. Alexey asked a clarifying question about whether the server initiates the exchange by sending a list of SASL mechanisms (answer is yes), in which case he thought this proposal made sense. Joe said the only need he can think of for the client to initiate the SASL exchange is in the case where the client did not completely trust the server authentication done at the TLS layer, e.g. the trust root was questionable, and wanted to fall back to inner authentication such as a SASL GSS-API mechanism which allows for mutual authentication and channel binding to be verified. Joe thinks this is an edge case, and that we probably do not need to support this. Joe asked whether there were any objections to just supporting a server-initiated SASL exchange. There were no objections to this at the meeting, and further resolution would be taken to the list. Alexey asked whether, if authentication using one mechanism failed, the client can try another one that has been advertized. Joe says he is not sure how the draft deals with this at the moment, but in the case where the server-initiated exchange only is supported, the server could resend the mechanisms again. Alexey said that he did not think it was necessary for the server to send the mechanisms again, as the client already has the list and can pick another one. But either way, the draft needs to explain how this is supported. Alexey says that supporting this functionality is common SASL usage. Other protocols allow it. Steve says that the draft does permit this now, where the PT-TLS responder can send another SASL Mechanisms TLV if additional authentication is needed. It does not explicitly call out the error case, but does not preclude it. 4)PT-Client as TLS Server The current draft allows the NEA Client to be a TLS Server so that the NEA Server can initiate posture validation with the client. The question is how to support server authentication in this case. The proposal is to require mutual authentication at the TLS layer, and not use SASL in this case, thus simplifying the protocol. Steve says that while he is in favor of this approach, he does not think we should prohibit SASL authentication. Joe says that currently the SASL authentication is tied to the role the NEA client and server are playing in the PT-TLS exchange. It seems unlikely that the client would use SASL to authenticate the server in this case, but its possible the server might want to do additional authentication of the NEA client. Hao Zhou says he believes the current draft says that the SASL request can be sent only by the PT-TLS responder. If we want to allow this case, then we would need to make a change. Joe agreed, and said that there are probably other areas that need to be clarified. Steve said that assuming we decide to support this, we can rewrite the text in terms of PT-TLS client and server (versus PT-TLS initiator and responder) to make the expected behavior clearer. To be continued on the list. 5)Channel Binding It is desirable to be able to bind authentication to TLS channel, when possible. For example, SASL GS2 mechanism provides for this. The proposal is to describe this in the document. What Joe is not sure about is whether there are other mechanisms that support this capability. Alexey indicated that SCRAM does. Joe asked whether they use the same data structure used in GSS-API for tls-unique. Alexey thinks so. He supports adding tls-unique channel bindings to the draft. Steve says there are a couple of sentences on channel binding in Section 3.8.1 of the current draft, but more text needs to be added. Susan asked whether there were other issues that the WG wanted to bring up. Alexey brought up the following additional issues: TLS Version: TLS1.1 is currently mandated. Concern that TLS 1.1 not widely deployed, and suggested that TLS 1.2 should be mandated instead. TLS 1.1. and 1.2 is available in libraries such as Opera, MS, OpenSSL (trunk version). The proposal is to mandate TLS 1.2. X.509 Certs: The draft does not specify what is expected in certificates, such as make use of RFC6125. RFC5280 is not sufficient as it has too many options. This works for the situation where client initiates TLS session, but there is an issue in the reverse direction, where the server may not know the client’s name. Stephen Farrell agreed that the reverse direction is tricky, and asked whether there are privacy concerns that need to be addressed as well. Joe indicated that we should note this as an issue in Privacy Considerations. PT-EAP: Nancy went through the comments received on PT-EAP I-D. Looking for more comments from the WG. The draft currently uses several acronyms to refer to the EAP method, the outer tunnel, or some combination. The proposal is to focus the document on the EAP method which carries the NEA data only, and refer to it as PT- EAP. Steve agreed saying we have enough acronyms already. The above requires changes throughout the document. Specifically, Nancy has proposed changes to simplify the abstract and introduction given the above. She has also incorporated a comment from Steve Hanna that allows the EAP method to run in an EAP tunnel method “or equivalent protection” Stephen Farrell raised the issue of what “equivalent protection” really means. Steve said that the tunnel properties are defined in RFC5209 and in security considerations. Stephen responded that this leaves implementers hanging, but this is acceptable as long as it is clear that a TLS tunnel method must be implemented. Hao said there are inconsistencies in the proposed text around requiring an outer TLS tunnel method, or “equivalent protection”. Joe raised the question of whether this text is implying non-TLS-based EAP tunnel methods. Steve clarified that he wants to make sure that we support the proxy case from one RADIUS server to another. Joe says he still has a lot of problems with that use case and believes there are security issues that need to be addressed in the document. Steve said that there is an agreement to use EAP tunnel method, but there is still disagreement on the proxy case. This needs to be addressed directly on the mailing list, and if the consensus is that it is unsafe to do so, the spec should prohibit it, and if it is safe to do so under certain conditions, the spec must state what those conditions are. Nancy then proposed to remove references to the TNC document within the main text, and add text to the acknowledgements section. Steve disagreed saying he thought it was important to let readers know that the IETF spec and the TNC specs are equivalent. The TNC specs will be updated to be the same as the IETF document. Stephen Farrell says that this should be taken offline to come up with text that makes everyone happy. Nancy also proposed that a new EAP type should be assigned to PT-EAP. Stephen F. asked about the process for allocating the new EAP type. Joe suggested that at the time of WGLC, EMU WG be notified. Stephen F. suggested removing the Appendix, which describes how the protocol meets the requirements. It is no longer needed. Hao asked why a version registry is needed in IANA considerations. If changes are made, a new RFC will be issued. Susan proposed not including support in PT-EAP for fragmentation, at least where EAP tunnel method transports are mandated. EAP tunnel methods will support sending packets of up to approx 64K as is, and if more posture information needs to be transferred, then there is an alternate mechanism to use which is PT-TLS. Steve says he is fine with this as it encourages people to do the right thing, and simplifies interoperability and testing. NEA Asokan Analysis I-D ======================= This I-D is referenced by both PT-TLS and PT-EAP I-Ds as informational. The question is whether the WG wants to make this a WG document with the intent to publish as an Informational RFC. A consensus check was taken and no objections raised. Stephen Farrell asked whether this would be useful to a more general audience, otherwise the text could be included in one draft and the other draft could reference it. Steve said that the draft is currently focused specifically on the Asokan attack in the NEA context, but it may be useful to raise awareness of the Asokan attack in general. Stephen F. suggested the draft be generalized so that it is not only specific to NEA, assuming this was not too much additional work. Joe said that it would be worthwhile investigating to see what it would take as he thinks the document would be useful to a wider audience. Next Steps: Susan summarized the next steps. The PT-TLS spec will be revised after all the issues have been addressed and another WGLC done. More comments are needed on PT-EAP. Hao and Kathleen volunteered to review the document. Joe and Steve will scope the amount of work needed to generalize the NEA Asokan I-D. Milestones ========== Susan went through a new set of proposed milestones, as listed on the slides. Stephen said that it looks like the NEA WG could be completed prior to the IETF in Paris, and that we should not assume that we need a meeting in Paris. It seems that with more mailing list participation, this is doable. The forcing function is that if there is insufficient mailing list discussion, then there may not be a meeting as agenda slots are tight. Meeting adjourned.