[Nea] Draft minutes for NEA WG at IETF 72

Here are draft minutes for the NEA WG meeting
at IETF 72. These have also been posted to the
meeting materials web site. Thanks to the
note takers. If you have any comments on or
corrections to these minutes, please send
them to the NEA email list by September 12,
two weeks from today. That will allow enough
time to get the corrections into the proceedings.

Thanks,

Steve

------------

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
_______________________________________________
Nea mailing list
Nea@ietf.org
https://www.ietf.org/mailman/listinfo/nea