Subject: [Nea] Meeting summary for May 18th

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Mon, 22 May 2006 18:34:08 -0700

Hi All,

Here is my rough meeting summary (for May 18th)...

Attendees-
Steve, Uri, Susan, Hao, Diana, Kevin, Mauricio, Thomas, Paul, Amardeep,
Ravi, Joe

Susan - plan for this draft?
Hormuzd - plan is to send 00 rev to chairs by Monday 3PM PST

PTT Requirements
Kevin -
1. The transport should use standard based protocols whenever possible.
2. The protocol should incur low overhead to accommodate for low
bandwidth links
3. The Protocol should support half duplex communication
4. No assumptions of the data being transported (size,type,format).i.e.
PA & PB
-Data is opaque
5. Integrity and confidentiality of the data being transported.
Should this be PTT or PTC?
- The protocol MUST allow...
6. PTT should be able to be fragmented, detect duplicates, and ordered
reassembled if necessary (reliable/guaranteed delivery)

*Should make no assumptions of the PTC - remove this
*Option for Server initiated? Client/server initiated -remove this,
already in the common reqs or use same text from common reqs

7. Should be able to do Mutual authentication, or NAA/server
authentication at a minimum or MUST. Allow for client authentication
Uri - thinks mutual authentication should be a MUST
Protocols MUST allow/support mutual authentication
John - doesnt agree that mutual authentication is a MUST
Hormuzd - bin this for now, revisit this

*Reuse of negotiated session key - remove this
*Should protect against MIM attacks (maybe) - remove this

John -
1. Transport requirements
a) Must be able to do Net endpoint evaluation prior to allowing access
to the net
	- this implies being able to do as part of tunneled EAP
conversation
- at least for cases where the access control uses EAP
	- for cases where EAP is optional we need to either require use
of tunneled EAP or define a different way to provide transport
b) Must be able top NEA while endpoint has access to the network
	- this implies that a transport must be created between the
endpoint
(NAR) and the Endpoint Authorizer (NAA)
		- this probably implies setting up a TLS connection
between NAR and NAA
		- addressing issues [who knows how to connect to the
other, who initiates the connection] are not resolved
	- the conversation between NAA and PEP is not well understood
for the already connected state

Steve - Good requirements but cannot be met by a single protocol
Hoa - same as server initiated or client initiated
John - not clear what wg would do 1b)
Kevin - rephrase 1 a& b. make into single requirement - agreement

c) Must have secure transport between NAR and NAA
	- this seems to imply that the identity of the NAR as well as
the user must be knownto the NAA
	- it is not clear to me exactly what the requirements for
knowledge of NAA by the NAR

Hao - is this a PTT requirement or generic req?
Paul - agree with kevin, bin this for now
John - take this discussion to the mailing list

2. PEP requirements

a) PEP must be capable of using RADIUS for control prior to allowing
access
b) We may define other methods of control [e.g. SNMP, DHCP, more generic
policy] for future use

3. Security

a) NEA should define requirements for ensuring the use of valid NEA code
at both client and server
b) NEA should describe dangers of allowing Agents access to clients in
terms of privacy for individuals and groups within organizations

Security Considerations

Action Items - 

Everyone review the text sent out by Uri and send comments to team by
Friday (tomorrow).

Hormuzd/Paul - Send out initial rev of the draft to the team for review
by Friday (tomorrow)

Hormuzd/Paul - Send out -00rev draft to chairs by Monday May 22nd 3PM
PST

_______________________________________________
Nea mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nea