[Nea] Draft NEA WG minutes for IETF71
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Nea] Draft NEA WG minutes for IETF71
Below are the draft minutes for the NEA WG for IETF71.
Please send corrections to Steve and me by Monday 4/21.
Thanks very much to the note-takers, Hormuzd Khosravi and Nancy Winget.
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: Tuesday, March 11, 2008
Time: 0900-1130 EST (GMT-0500)
WG Charter: http://www.ietf.org/html.charters/nea-charter.html
WG Tools: http://tools.ietf.org/wg/nea
WG email: nea at ietf.org
0900 Administrivia
Blue Sheets
Jabber & Minute scribes
Agenda bashing
0905 WG Status
0910 Discuss IESG Requested Changes to NEA Requirements draft
draft-ietf-nea-requirements-06.txt
0930 Review Proposals for NEA Protocols:PB-TNC, PA-TNC, PA-TNC Security
draft-sahita-nea-pb-tnc-00.txt
draft-sangster-nea-pa-tnc-00.txt
draft-sangster-nea-pa-tnc-security-00.txt
1100 Consensus Check - Shall We Adopt These As WG Drafts?
(To Be Confirmed On List)
1120 Review Milestones
1130 Adjourn
WG Status:
Susan Thomson reviewed WG status since the last IETF.
--- Nea-requirements-05 submitted to IESG (12/6/2007)
--- IETF Last Call issued (12/10/2007-12/24/2007)
--- Call for PA and PB proposals (01/03/2008)
--- IESG reviewed nea-requirements-05 (1/10/2008)
--- IESG reviewed nea-requirements-06 (1/28/2008)
--- PA and PB candidate submissions (2/18/2008)
draft-sangster-nea-pa-tnc-00.txt
draft-sahita-nea-pb-tnc-00.txt
draft-sangster-nea-pa-tnc-security-00.txt
Meeting Goals:
Susan stated there were two main goals for the meeting:
1. Resolve remaining IESG issues with the NEA requirements draft
2. Determine WG consensus for adopting candidate proposals as WG drafts
--- PB-TNC
--- PA-TNC
--- PA-TNC Security
Consensus Check process:
Susan reviewed the consensus check process. An initial consensus check
would be taken at the end of the meeting after the candidate proposals
have been reviewed, and then the same check would be done on the
mailing list.
For each of the proposed drafts, the following question would be asked:
Do you support adoption as WG draft?
Possible answers:
1. Yes
2. No
3. Defer
1) means that the draft is regarded as a good foundation for a WG -00
draft. The draft will be treated as any I-D -00 version where updates
are made based on WG consensus.
2) means that the draft would not form a good basis for a WG draft.
3) means to defer a decision based on some further action taking place.
NEA Requirements Status:
Kaushik Narayan reviewed the changes that had been made to the NEA
requirements draft based on IESG feedback.
One concern has been that some PT choices would not be able to meet
requirements for reliable bulk data transfer. A change has been made to
Section 5.2.3. of -06 version of the requirements draft to acknowledge
that one PT may not be able to meet all requirements and describes
possible deployment considerations.
Tim Polk said that he thought the IESG wanted to see a new requirement
for PT.
Steve Hanna said he thought this could be addressed through a wording
change.
Tim responded that if that addresses the IESG concern, then that would
be ok.
Steve said that, either way, this change would need to return to
mailing list.
Another IESG concern had been regarding MITM attacks on NEA endpoints,
and attacks on components that trigger posture assessment.
Clarifying text has been added to Section 8.1.3 to address these
concerns.
Other comments were mainly out of scope of NEA WG charter.
GEN ART review comments have been addressed in -06 version.
Alan Breese raised the issue of dealing with the lying endpoint problem.
Tim pointed out that this was outside the scope of the charter,
although the intent is that the NEA WG protocols accommodate solutions
to addressing this problem.
Susan asked about next steps for addressing IESG concerns re the
requirements draft.
Steve responded that Paul Sangster is working with the IESG to resolve
the PT concern. A new -07 version will be posted and changes reviewed
by the mailing list prior to sending to the IESG.
Review of PB-TNC:
Steve described the PB-TNC protocol for carrying PB messages between a
Posture Broker Client and Server. He reviewed the protocol
requirements, state machine and protocol format, and then took
questions from the working group.
Kaushik said he would send editorial comments to the mailing list.
Kaushik asked about how the protocol handled multiple sessions, possibly
over multiple PTs.
Steve responded that multiple sessions can be supported by assigning
a different connection ID or socket number to each session. This would
be handled through APIs, which are not in scope for this WG.
Kaushik raised the issue of supporting server-initiated reassessment
given the half-duplex nature of the protocol.
Steve responded that this is an important issue. If the WG consensus is
to address this issue, it could be in a subsequent draft.
Tim added that adoption of this proposal as a -00 draft does not
preclude such changes, assuming it is agreed that the draft provides a
sound foundation for doing so. It is good to highlight such issues, but
the draft should not be regarded as fully baked.
Gary Tomlinson says there are issues to be worked through, but believed
the draft provides a solid starting point.
Yaron Sheffer queried the size of the Private Enterprise Number.
Steve clarified that it was 24 bits.
Yaron asked whether there was a need for conflict resolution if two
servers initiated a posture exchange at the same time.
Steve said the assumption is that this use case would be supported
through distinct sessions.
Yaron asked for clarification regarding how information was routed
between Posture Collectors and Validators. Are Posture Collector
Indetifier (PCI) and Posture Validator Identifier (PVI) types or
instances?
Steve answered that the PA subtype indicates the type of information
the PC and PV are reporting on e.g. anti-virus. PCI and PVI indicate
the instance.
Kaushik asked about the reason for vendor-specific identifiers in PB.
Steve responded that this supports vendor-specific PB message types.
Kaushik says need to take offline to clarify.
Susan asked why assertion attributes had been omitted from the spec.
Steve said it was not part of the requirements. There was no particular
reason for omitting it in the first version, but rather it was mainly
due to lack of time to consider a proposal.
Jeffery Dion asked about queuing up messages prior to sending them for
efficiency purposes.
Steve responded that this could be done, and was an implementation
issues versus a protocol issue.
PA-TNC Review:
Steve described the PA-TNC protocol which carries posture attributes
between one or more Posture Collectors and Validators. He reviewed the
requirements, design and protocol format, and then took questions.
Kaushik raised the question again of the need for vendor identifiers at
both the PA and PB layers and suggested that there may be alternate
ways to support vendor-specific attributes that could be taken to the
list.
Gary Tomlinson asked about constraints on port filter semantics. It was
agreed to take this issue and comments on other posture attributes to
the list.
PA-TNC Security Review:
Steve described the PA-TNC security protocol which secures
communication between Posture Collectors and Validators and is based on
Cryptographic Message Syntax (CMS). Steve also presented a list of
concerns regarding the draft including the need for review by CMS
experts, data size, implementation complexity and ease of
configuration of PC and PV authorization.
Michael Peck questioned the MUST requirement for including the signer's
certificate.
Steve agreed that client may not need it.
Michael said there are many options in the spec which may need to be
trimmed down.
Kaushik shared Steve's concerns re deployability. He suggested
deferring a decision on PA-TNC security until further progress has been
made on PA and PB and the implications are better understood.
Steve said that given the publish/subscribe model, there is some
concern regarding the appropriate authorization for Posture Collectors
and Validators.
Gary concurs re concerns, and believes that most people will not need
this level of security, and that PT security is sufficient.
Kaushik added that one of the original reasons for PA security was
because server components are not co-located. However, it is possible
that the security issue can be addressed by securing the vertical
protocol itself when it is defined.
Steve agreed that this was one possible approach.
Yaron asked whether mutual authentication is required at the PT layer.
Steve answered yes.
Yaron said that he is still confused on message routing between
different components.
Steve explained how individual instances of PC/PV are identified and
clarified the use of the correlation ID.
Gary added that the "wildcard" usage in PA needs to be clarified.
Steve agreed and, said that, as Nancy pointed out on the mailing
list, it would be good to have examples.
Consensus Check:
The following consensus question was raised for each draft:
"Do you support adopting the draft as a WG draft?"
1. Yes
2. No
3. Defer
There was unanimous support at the meeting for adopting PA-TNC and PB-
TNC as WG drafts. A majority supported deferring the decision on the
adoption of PA-TNC Security until more work has been done on the PA and
PB protocols so that the protocol implications are better understood.
Tim said that the next step is to post this same consensus check on the
WG mailing list.
Kaushik asked whether there are any IPR claims to be aware of.
Steve says none that he is aware of so far.
Milestone Review:
Susan reviewed the milestones saying that these have not changed since
review at the last meeting. They have been posted to the mailing list
and no issues raised.
Tim agreed that these milestones could be added to the charter now.
Next Steps:
If consensus holds on adopting PA-TNC and PB-TNC, Tim suggests
these drafts be published as -00 WG drafts. The PA-TNC security
draft should be left as an individual submission.
Meeting adjourned.
_______________________________________________
Nea mailing list
Nea at ietf.org
https://www.ietf.org/mailman/listinfo/nea
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.