*Attendees*
Egon Verharen (chair), SURFnet
Jill Gemmill, UAB
Stu Jacobs, Verizon
Eric Nielsen, Sylantro
Tom Barton, Memphis
Samir Chatterjee, CGU
Nadim El-Khoury, UNC
Bob Morgan, Washington
Jonathon Tyman, Internet2
Ken Klingenstein, Internet2
Steve Olshansky, Internet2
Ann West, Internet2/Educause
Jeanette Fielden, Internet2

*Discussion*

ITU Security Profile: Security issues are discussed under the H.235 standard. At the February 11-14 meeting in San Jose, CA there is the opportunity to contribute to the discussion on security profiles. H.235 version 3 is due to be voted on in May 2003. Nadim is still working on his document. His idea regards H.323 Annex K and how the http process can be combined with OpenSAML to give that information to the endpoint to forward to the gatekeeper or the proxy. Some of the flow information and policy decision points from Jill's H.323 flow diagram for Annex D will likely be incorporated as well. Nadim will have it done in time for the meeting.

Stu Jacobs of Verizon and Eric Nielsen from Sylantro discussed their authentication model for SIP. What they are struggling with is a way to provide relatively strong, easily deployed, authentication for low cost SIP devices, specifically SIP phones, which would not require PKI infrastructure or any significant technical expertise on part of the owner to deploy. They came up with a lightweight approach that would also be able to support the existence of NAT between the client's device and the serving proxies without the client device having to know that NAT is there and be able to handle fail over between proxies. (People expect dial tone every time they pick up a phone). If you use the security mechanism spelled out in SIP the only robust approach is Ipsec and that doesn't support failover from one proxy to another or failover of registrars. Their goal is to solve the key management problem inherent in any kind of strong authentication and then use Ipsec esp null encryption with SHA-1-96 to do the actual authentication of the messages while not exposing the users pass phrase too often to network traffic.
After the client plugs in their SIP phone and enters their user ID and pass phrase (both assigned by the service provider) the phone boots up it and does a public private key pair generation process based on using information from the net it's plugged into with enough entropy to do at minimum a 512 RSA key. Uses the pass phrase with a HMAC-SHA-1-96 to digitally sign a message that says who I am and here's my public key and send it to the SIP registrar it's been instructed to use. If there is NAT in the middle then that box needs to be SIP aware and it would see this message, add its own public key as an appendix and wrap that in a SHA-1-96 signature and pass that to the registrar. If the registrar sees two signatures it knows that NAT is involved and it will generate a strong symmetric secret key using the public keys of both the NAT and client device to encrypt the secret key, and send copies back to both the NAT and the client device and notify the proxies. The client can then digitally sign its invitation using a SHA-1-96 null encryption esp, which goes to the NAT box which can tweak the IP addresses, then sign it and pass it on to the proxies.

The document that they wrote was intended to be a distillation of a way to use password-based authentication that is consistent with maintaining those passwords securely. I.e. not leaving them on phones that can be broken into and the password recovered. The idea is to enable the phone to act as a persistent proxy on your behalf so that when it reboots it and use the public key on the phone so it can reestablish your connection to the proxy without having to re-enter the password. The concept of what's persistent is somewhat strange. The relationship between the device and the proxy is persistent although it can be cut off administratively or limited by policies. User passwords relate only when you initially connect the phone to the proxy server.

The approach for dealing with the NAT is relatively new and having it part of the trust association between the proxy, registrars and clients hasn't been published yet. For any mechanism to alter information, it needs to be part of the trust chain. The current way SIP does it is each entity gets to insert their own little piece in this larger package and assert their own identity, which can't be checked on an ongoing basis if there are many identities involved. If you have secure ability to manipulate messages then you can actually manipulate the packages of the small bits of authentication within the larger package anyway. As a vendor the desire is to check if the entire package is authentic or not. It gets expensive quickly to check all those pieces, and that's where errors can happen as well. The preference is to be able to take a packet off the line and quickly determine it's authentic. There is a need for device level authentication, particularly from the Service Provider viewpoint and strike a balance between absolute and reasonable security.

The idea is to prevent the private side of key being sent across the network and minimize any distribution of it. The public private key pair has no value or identity to anyone until the end user gives the URI and password in context of the key pair. I can authenticate with some registrar that determines that I am on this device with this public key, and use the public key as a proxy for services within that domain. The registrar now knows my public key. When I need to make a new authentication with yet another new service the registrar can use that public key to regenerate a session etc. Policies are needed to define things such as how long that public key is associated with my identity. The management of the pass phrase is separate from the persistence of the public key. I.e. I can log into the phone with the pass phrase, five minutes later change the pass phrase, but in no way is the public key and its relationship to the phone altered.

Concerns were expressed over identity theft. Leaving a private key on any device has risks that need to be thought through. There is less risk if the private key defined identity is only valid within a certain context and for a constrained amount of value then you're exposing yourself to far less damage if the device is compromised and the key is extracted. Jill pointed out that there is a usage behavior that people are already comfortable with; possession of the physical device is the users responsibility. Physical control over the telephone is the basis of security on the PSTN.

The group discussed several aspects of the approach and agreed that there was common ground and a need to think in contexts outside of higher education, and from an intellectual property perspective. The next step is arrange for Stu, Eric, and Jon Peterson to all be on the same call to discuss how the various different efforts can work together going forward.
[AI] Steve will try to coordinate having Jon on the call in January.

Stu and Eric did republish Jon's critique on the requirements document, with permission, back into the SIP work group. They will forward Jon's critique to VidMid group as well.
[AI] Stu/Eric: e-mail Jon's critique to the VidMid list.

Jon's ITEF draft: He is working on it with Doug, and a draft should be available in early January.

SIP identity draft: Jill expects that a draft of SIP identity will be circulated next week after undergoing one more round of review.

Nadim is creating a document together on how to install the tool and what version of software packages you need on the machine. They are working on some bug fixes as well, which will be released as soon as they're ready.

Samir expressed concern over putting domains names and IP addresses on white pages. If you are a zone administrator you can set the IP information so it's not displayed. When you search on a zone, the gatekeepers IP numbers are not displayed. Also, it was decided not to put IP numbers into the LDAP directory currently. The LDAP server can be configured so that only certain people can retrieve the IP numbers. You can set it so that if it's searched via the web, not authenticated, the IP numbers won't be displayed.

Please look over the SIP SAML flow document that Samir forwarded to the list and send feedback. Requirements want SSO and use SAML assertions during the registration, invite, and inter-realm processes. It is a call flow model that is seriously being considered for implementation.

Jill requested feedback on the flows she's circulated to the list. The flows sent around are for the paper that she and Samir are writing for a middleware developer's conference. The flows represent what's available today to work with in H.323: how one could use a federated approach and SAML assertions with a particular H.323 security annex. The need is determine how to overcome the fact that in H.323 the client talks to the gatekeeper over UDP. The use of certificates makes securing Annex E preferable to Annex D, which is oriented on username/password. As far as Radvision is concerned they currently only have Annex D support in their stack. X.509 support is planned within six months or so.

Authn/Z issues will be addressed in the VC calls for the moment. When there are enough items for discussion the separate Tuesday call will resume.

The next call will be January 13, 2003.