(1) VNET TEAM MEETING IN ATLANTA MARCH 24

We are definitely having a face-to-face meeting in Atlanta on Monday

March 24, 2003. Would each person who is planning to attend please

confirm your attendance to this list so that I know how many to plan

for. Remote participation via H.323 will be available; still, we

encourage as many of you as possible to attend in person.

Please see http://www.vide.net/conferences/spr2003/ for hotel and

meeting location information. We will be using the same hotel and have

a meeting room reserved in the GCATT facility, same place that the

workshop will be held the next day.

I will see that we have breakfast and lunch served for our meeting; if

there are any special dietary requests please let me know.

Suggested Agenda for the meeting:

* Review deliverables list and status (jason is working on

updating the list and status of each item)

* Distributed Directory search

* Testbed organization and Management (includes discussion of

GUI for loading commObjects)

* Cookbook organization

Please suggest any additional topics, if you have any.

(2) CGU SIP software has been released - people have been testing it out

some.

http://ncl.cgu.edu/sipclient/ Tyler asked if there was going to be a

demo at the vide meeting. Samir may send someone to Atlanta in his

place to demo

(3) Update from ITU meeting from Nadim

* ITU Wanted new attributes - H.320 ISDN

* No new attributes for H323Identity

* Had to explain LDAPServer - Endpoint - GK (how they

interact)

* Appending diagrams to the document

* ITU would like a better explanation of Why this is needed? -

Jason will try to write something up on this topic.

* SIP

*Requested attributes to be added

* Esp. dealing w/ certificates

* How to handle S-MIME

*ITU would like to continue w/ SIP

(4) SIP Identity

*Samir - Need to get IETF's blessing on SIPIdentity

* Tyler - Should we get Henning(sp.?), Peterson(sp.?), Sicker in on

this?

(5) Marketing - we need to do a better job (perhaps cookbook is a

vehicle) for explaining why what we're doing is cool.

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

----

(*) Samir requested a restatement of the steps and assumptions for

enterprise

authentication - jill posted a summary to vidmid (because the

request had originated there, but repeats the same info here:

If you refer back to the presentation from the Fall 2002 Internet2

member meeting,

(http://www.dpo.uab.edu/~jgemmill/Presentations/Year_2002/Internet2AUthN

Z2002.pdf) you can review the constraints imposed by a desire to live

within the protocol's EXISTING standards for authentication and

security.

Given our desire to produce runnable software this year for testing, we

have decided to:

(a) test Cisco's implementation of backend gatekeeper authentication

service, which employs RADIUS to tie in to enterprise authentication.

This will be accomplished by Egon's TestBed activities.

(b) leverage adoption of commObject within the ITU to introduce

authenticating endpoint software using LDAP bind to tie in to enterprise

authentication and to obtain access to the correct h323Identity objects.

We are working with RADVISION to finalize implementation details and

expect to complete this process shortly. It will use H.235 Annex D

because that is the only security profile supported in their STACK (or

anyone's stack, as far as we can tell). Annex D uses a

videoconferencing password as a shared secret between Gatekeeper and

EndPoint; we provide a place to store this password in h323Identity

(h323Password); we use LDAP bind to make sure you are the person who

should have access to this password; we suggest the videoconferencing

password could be created dynamically to reduce likelihood of the

password being stored statically anywhere other than in the commObject.

What we accomplish with this approach is:

(1) use of enterprise authentication in H.323 [NEW]

(2) use of commObject to associate identity with security credentials

(the videoconferencing password) [NEW]

(3) use of existing H.235 protocol for encrypting control and media

channels in a manner based on enterprise authentication. [NEW]

(4) use any shortcomings of this implementation to create improved or

new approaches to security for H.323

(c) We took a close look at what would be required to make current H.323

standards work with the Shibboleth as currently exists, sans API, which

was summarized in the "lunchtime napkin scribble" model circulated to

this group. Our conclusion from this process was that we should be

looking for a better approach. For rapid adoption in the market place

(another constraint) we believe that developing a security profile for

Annex E (utilizing digital certificates) will be better than trying to

get an entirely new approach ratified by the ITU. An Annex E 'Profile'

would recommend a specific way in which digital certificates should be

handled; this, by the way, is why we have a high level of interest in

credentials translators and KX.509 experiences.