Minutes from NEA WG Meeting IETF 72 in Dublin, Ireland July 31, 2008, 9:00 AM - 11:30 AM Chaired by Steve Hanna and Susan Thomson Notes taken by Eugene Chang, Paul Hoffman, and Ravi Sahita 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 for IETF 72 NEA WG meeting ================================= Date: Thursday, July 31, 2008 Time: 0900-1130 IST (GMT+0100) 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 Blue Sheets Jabber & Minute scribes Agenda bashing 0905 WG Status 0910 Protocol Overview 0915 Changes in -01 version of PB-TNC and PA-TNC: http://www.ietf.org/internet-drafts/draft-ietf-nea-pa-tnc-01.txt http://www.ietf.org/internet-drafts/draft-ietf-nea-pb-tnc-01.txt 0930 Protocol Flows 1015 Proposed Changes in -02 version of PB-TNC and PA-TNC 1100 Open Discussion 1125 Review Milestones 1130 Adjourn The agenda was reviewed with no change. Minute takers volunteered. Susan Thomson reviewed WG status. Since IETF 71, WG accomplishments include publication of the NEA Overview and Requirements document as RFC 5209 and publication of WG drafts on PA-TNC and PB-TNC. Steve Hanna gave a quick overview of the NEA reference model and showed an example of PA-TNC messages nested in PB-TNC messages inside PT. Steve Hanna described the changes in the -01 version of PB-TNC and Kaushik Narayan described the changes in the -01 version of PA-TNC. See the slides for details. They both asked new readers of the specs to point out areas that are confusing so that they can be made clearer. The Design Considerations sections can also be enhanced to explain why certain design decisions were made. Paul Hoffman asked how will standardization of vendor-specific PA subtypes and similar values qualified with a vendor ID work. If a vendor has been using a particular PA subtype with vendor ID 17 and then they want to standardize that, would it continue to use vendor ID 17 or switch to vendor ID 0? There is no incentive for them to move to vendor id 0 since that will break their then current implementations. Kaushik said vendors can publish vendor-specific subtypes on their own but if they want to standardize something, they should move it to vendor ID 0. Paul said that other WGs that have tried this approach have found that it doesn't work. Making the transition to vendor ID 0 is too painful. We should allow standardization of PA subtypes with non-zero vendor IDs. Steve asked if Paul has an example of a protocol where this idea is used successfully. Paul said no, he doesn't know about anyone who has used this idea. He did point out that in IKE there are vendor-specific values and virtually 2/3 of the values used are vendor-specific but widely used. Kaushik said that a vendor could always create an informational RFC documenting a vendor-specific PA subtype. That's similar to what people have done with EAP methods. Dave Mitton pointed out that many RADIUS vendor-specific attributes have become de facto standards, like the wireless key wrapping RADIUS attributes. He cautioned that if we do not provide everything that people need in vendor ID 0, they will create vendor-specific values that will become widely used. Steve said that we have identified and specified as many standard attributes as many as we can but we know we won't be able to get all of them. Dave said that standardizing as many as you can is good. Kaushik commented that he expects that many more vendor-specific NEA attributes will be created than the number of RADIUS attributes since vendor-specific Posture Collectors and Posture Validators can easily be created. Kaushik walked through the example protocol flows in the latest PA-TNC and PB-TNC specifications. See those specs for details. Ravi Sahita explained changes proposed for PB-TNC version -02. First, we propose moving the PB-Batch-Type to the PB-TNC header. This is a 16 bit integer with enumerated values that indicate the type of the batch. It's currently carried in a PB-TNC message of type PB-Batch-Type but we require that there be one and only one such message in each batch so it seems that it would just be simpler and more efficient to move this field into the PB-TNC header. We already have 24 reserved bits in that header so there's no problem with making this change. Second, when a full-duplex PT is being used, we'd like to allow either the NEA Client or NEA Server to request a retry at any time. Right now, PB-TNC is strictly half-duplex even if the PT is not and that tightly restricts when the NEA Client and NEA Server can request retries (only when it's their turn to send). That causes problems if one side detects a problem such as a change in policy or in endpoint configuration. They might have to wait a long time to be able to signal this problem and request a retry. In fact, they might have to wait indefinitely. This change is not a big one but it does modify the state machine to indicate that whenever SRETRY is allowed, CRETRY is also allowed and vice versa. Paul Hoffman asked "you said reset and retry - which one is it?" Ravi explained that CRETRY and SRETRY are the formal message types. When a CRETRY or SRETRY is sent, it is a signal to the Posture Broker Server or Client side respectively to ignore what was sent previously and "reset" the NEA session. Third, a PB-TNC RESULT batch currently includes an Access-Recommendation that contains one of the values Access Allowed, Quarantined, or Access Denied. There's currently no way in PB-TNC to indicate whether the NEA Client was found to be compliant with policy. So we suggest adding posture assessment that could have values like Compliant, Non-Compliant, Non-Compliant Major Issue, Error, and Don't Know. Paul Sangster explained changes proposed for PA-TNC version -02. First, we propose changing how attribute correlation is handled. Currently, a Correlation ID is used to handle the case where a single Posture Collector is able to gather information on several products. This is somewhat unusual but it causes problems since that Posture Collector might send a single PA-TNC message with multiple Product Information, Numeric Version, and Operational Status attributes, for example. Which Product Information attribute goes with which Numeric Version Attribute? Today, we solve this problem by tagging the attributes with an optional Correlation ID. The proposed new solution to this problem is to have a Posture Collector that wants to report on several products use a different Posture Collector ID for each product that it reports on. This removes the need to have a special protocol feature to handle this case. Effectively, it pushes the tagging up the stack into PB where we already have a field that can be used to solve this problem. The main advantage is that it simplifies the protocol. The main disadvantage is that it complicates the Posture Broker Client and Posture Collector implementation if they want to handle this case since they need to handle "virtual" Posture Collector IDs. Steve pointed out that the PA subtype on the slides should be "AV" (not "OS"). Paul agreed. The second suggested change in PA-TNC -02 is the addition of an Assessment Result attribute that would allow a Posture Validator to inform a Posture Collector about the compliance decision for a component. The third suggested change in PA-TNC -02 is the addition of a Remediation attribute that would allow a Posture Validator to send remediation instructions to a Posture Collector. An Open Mic session followed. Paul Sangster started off the Open Mic by soliciting suggestions for additional attributes (standard PA-TNC Attribute Types) or components (standard PA Subtypes). Rob Nagy said that PA-TNC looks very PC centric. It needs to be more general, including things like existence of processes and existence of files. Paul said our attributes are generally at a higher level. Steve said that if you look at what is commercially deployed, admins often want to deny access if a particular process is running or require that a particular process is running to get access or check for the existence or value of a particular registry entry. It's not clear that this improves security much but it is commonly requested. Kaushik asked "how do we decide which attributes should be standardized?" Is it by WG consensus? Steve and Paul explained that the current specifications say that this is done by IESG approved RFC. Tim Polk said that the NEA WG should think carefully about this process. Think about what we need for a new attribute. Do we want to require a specification? Do we need to avoid exhausting a small number of identifiers? Do we want to ensure consistency and avoid overlapping attribute types? Tim suggested that we choose the lightest weight process that will meet our goals. Steve pointed out that there are 2^32 IETF Standard PA Subtypes and 2^32 IETF Standard PA-TNC Attribute Types so we don't need to worry about exhausting the set of identifiers. However, we do need to revisit this issue on the NEA list. Since the time the specs were drafted, RFC 5226 has been published and that changed the set of categories for IANA Considerations so we must reconsider our current decision, in any case. Kaushik suggested that we ask the IETF community what works and what doesn't. Paul Hoffman said that it's all over the map. Everyone has different opinions and most of those are not based on actual experience because very few people have extension mechanisms that have actually been used more than twice. The ones that need lots more generally use expert advisors so almost nobody even knows when an identifier is given out. The apps folks have language tags and language tag subregistries. An expert does a sanity check and passes almost everything through, not based whether he likes it or not. With ipsec, we had to go through RFC. Half the people love it because it prevents bad things from happening, half the people hate it because it's so slow. You won't get good advice from the past. Just decide how much effort you want to expend and see if Tim's OK with that. And remember that you can change this a few years from now. Past experience has shown no one can agree because some people think a small group of people should be able to get things standardized quickly and other people think it should be carefully controlled. Tim said the WG needs to decide what's right. If you want advice, you can ask Michelle Cotton at the IANA desk about the scale of things and what the implications might be. For this kind of thing that seems like it might have a lot of volume, you should not have one person that is the stuckie. You should have a team of experts. Steve suggested that we discuss the pros and cons of expert review versus IESG-approved RFC. How bad would it be to have lots of attributes standardized but not widely used? Paul said that would not be horrible but we DEFINITELY should require a document so that you can see things on the wire and know what they are. Kaushik said we need to decide whether we are going to allow vendors to publish specs for vendor-specific attributes. If they become widely used, they can move them into the IETF namespace. That way, we don't require much work by the IETF but the downside is that there would be pain required to move from the vendor-specific IDs to IETF standard ones. Steve said that if we encourage vendors to develop their own attributes and then get them documented within IETF, those attributes may favor that vendor's products. For example, the version field might be numeric and not support letters. Kaushik said we need a rational way to decide which attributes should be standardized. Rob Nagy said we should probably start tighter and loosen. It's hard to go the other way. Paul said there may not be many proposals anyway. If there are, we can loosen things up then. Ravi said that vendors could ask on the NEA list whether anyone else is interested in a new attribute. If so, it should be standardized. If not, it should not. Also, we should think about including firmware version and other platform-level attributes. Paul said that sounds like the IANA would receive requests and consult a triage team to decide which way the attribute should go. Tim said that we should put some real effort into making the standard attribute list as complete as possible up front. Otherwise, many vendors will create their own proprietary version of an attribute and then it will be too late to create a standard version. You'd really like your expert group to decide whether an attribute is OK to be vendor-specific or needs to be standardized. You don't want too many duplicate attributes. Paul Sangster said that we already have lots of shipping products in this area so we do have a lot of experience. Paul Hoffman said that we should use a lighter weight process like expert review so that we can quickly get new ideas standardized. I also suggest that you look at those shipping products early on to see which attributes they support and use that information to decide which things should be standardized. If there's anything that two companies are already using, standardize that. Of course, this assumes that vendors are willing to disclose the attributes that they send. Steve pointed out that you can generally look at the admin UI and immediately know pretty much which attributes are being sent. Paul said that vendors will generally be glad to have their semantics win. Even vendors that are gone may have had some really good ideas. Kaushik said that things are always changing so we should not just focus on the old attributes. Yaron Sheffer said that having a lightweight process in EAP resulted in many undocumented methods. You should at least require a document. Paul Hoffman said that with EAP you need more than just a data format. You need to describe a whole protocol. Maybe that's why people didn't write up specs. Steve said that if we have an expert, we should tell the expert to require a specification permanently archived in a central public location. Paul said it's not good enough to just have a URL on some vendor's web site. That will change or go away. We should copy the text and paste it into the IANA registry. It should be short. Paul Hoffman asked for a straw poll on this question: Should we require some sort of permanent documentation in order to get an identifier from the vendor id 0 namespace? There was unanimous agreement that we should. There were no more comments. Susan presented the NEA WG milestones. The next step is to update the PA-TNC and PB-TNC drafts. That is supposed to happen in August. WGLC is scheduled for September. This schedule is aggressive. Please review the WG drafts and comment on the mailing list. Kaushik had a quick question. Where will the process for allocating identifiers be documented? In PA-TNC or PB-TNC? Steve said both. They both include IANA Considerations. Meeting adjourned