Meeting Minutes 2003 05 26

Agenda:

Review / Modify Agenda

Accept Minutes of 5/12/03 Meeting

Review Current Action Item List

Discuss SIP-AD issues

Disputed RFC

LDAP Password Issue

IETF RFC for SIP

Cookbook Materials

Public Relations

Attendees:

Jill Gemmill - U.A.B.

Jason Lynn - U.A.B.

Aditya Srinivasan - U.A.B.

Tyler Johnson - U.N.C.

Samir Chatterjee - C.G.U.

Tarun Abhichandani - C.G.U.

Haiqing Li - C.G.U.

Action Items:

* Tyler - Submit "Summary" to the group

Meeting:

<Jill>

The minutes from last week can be accepted, but I was the one who sent

the documents to the SIPPING group and not Tyler. [Note: This has been

corrected in the previous minutes]

What does the RFC says about manual client configuration?

<Tyler>

It is RFC 3261 Section 10.2.6. There are three ways to configure. One:

configuration is accomplished outside the scope of RFC. Two,

configuration is accomplished using the address of record (aligns

perfectly with Annex O specification). And three, configuration is

accomplished using multicast.

The architecture we are proposing makes sense in the H.323 world

(non-URI based), but not the SIP world (URI based). Though, I can think

of some situations why the usual SIP registration should be broken (eg.

to give each endpoint a separate configuration).

I think we should have LDAP as a backup registration method since the

RFC allows for a manual configuration.

<Tyler>

We have to produce an RFC to present to SIPPING to be released mid-July

after ITU-T release the documents. We have been given the "Ok" from

ITU-T for the process of going forward with SIPIdentity. This is an

informational RFC, not a standards RFC.

<Jill>

We should tackle old issues first (i.e. LDAP Passwords).

<Tyler>

The SIP Endpoints don't need much to self-configure and might not take

advantage of many of the attributes like H.323 does.

People are not comfortable with passwords in LDAP; sipPassword in

particular.

Registration only lets call servers know who you are. The far end user

still cannot authenticate you personally. We are missing some pieces of

authentication here. The end user certificate scenerio may be best.

<Samir>

Storing passwords in LDAP is something we can do, but no vendor will do

this. Exploring certificates is the next step we can take. We need to

explore details of how authentication can be accomplished. We believe

that the new DynamicSoft stack is capable of handling certificates.

<Jill>

In the Shibboleth world, the AuthServer can digitally sign a message to

authenticate. A signed message is an example of the type of message

that SIP can carry.

<Tyler>

I believe that with Shibboleth you authenticated to a realm but you

cannot determine who it is exactly.

<Samir>

The AuthServer can send a message saying who it is.

<Jill>

Yes, the AuthServer can divulge information as long as parties agree on

which information to divulge. The information is carried through S-MIME

messages.

<Samir>

Whether SIP messages can be signed is a stack issue and we don't know if

the DynamicSoft stack can handle this.

<Jill>

I wouldn't get overly hung-up on passwords being stored in the LDAP

server because it is only a security credential. Meaning, certificates

can replace passwords as that credential. The proof of concept is just

to show security credential retrieval.

<Tyler>

It is interesting that you brought up that intermediate proxies need to

look at headers, so you can't encrypt the headers of the intermediate

proxies or the proxies will need the ability to decrypt the headers.

<Samir>

This is why we cannot do end-to-end encryption in SIP.

<Tyler>

There are quite a few examples of using S-MIME in the RFC.

<Jill>

(To Samir) If we can get you to go ahead and deliver what is on the

schedule, we can have something for the testbed.

<Samir>

We are concerned about the SAML component. Did we promise to do that?

<Jill>

All we said was that we would evaluate Shibboleth.

<Samir>

So the decision is to move ahead with passwords and then try to get rid

of Oracle on the server side.

<Tarun>

The Windows username and password is stored in the registry.

<Jill>

The only security problem with this Active Directory approach is if

there is a machine that more than one person uses then it is possible to

read names, etc. out of the registry.

<Tyler>

I am not enthused about this because there seems to be a lot of

Microsoft-only development. The user should have to type in the

username and password twice which gives the flexibility for pointing

authentication elsewhere.

<Tarun>

Using LDAP instead of Active Directory would be a different

implementation. OpenLDAP doesn't have enterprise authentication.

<All>

Not true. You can authenticate against LDAP.

<Samir>

We will discuss this via email as there is no need to hold up this

meeting.

<Jill>

Let's talk about public releations.

<Tyler>

We have consent on H.350 from Study Group 16. Won't make it through

internal processes of ITU until mid-July. This is not a standard

officially until then. We need to spend time now to write a press

release to release at the time it becomes a standard. The ITU is

interested in helping us with the press release. Internet 2 and ViDe

may be interested in the press release as well. We need to plan it out

and plan deliverables.

We received some feedback from members of ITU. The summary written is

what they wanted to read. We need something we can hand a directory

manager to read. This may be an important part of the cookbook.

<Jill>

Send your summary.

The cookbook table of contents needs to be organized more functionally.

By next meeting hopefully have something more along those lines.

<Tyler>

We should have a meeting only on this.

<Jill>

Next week?

<All>

Yes.

<Samir>

The school dean met with the National Science Foundation and spoke with

Kevin Thompson and he would personally like to download the client and

participate in some meetings. We need to get the MCU up and running.

<Jill>

We need to decide before June 16 what we want to show at Internet2 fall

meeting.