Minutes from the 3GPP Requirements to SIPPING ad hoc meeting
Thursday 13th December 2001 – 22:00
Minutes taken by Georg Mayer
Attendance:
Rohan Mahy roha@cisco.com
Vesa Torvinen vesa.trovinen@lmt.ericsson.se
Jonathan Rosenberg jdrosen@dynamicsoft.com
Guanglu Wang guanglu_wang@3com.com
Jayshree Bharatia jayshree@nortelnetworks.com
Senthil Sengodan senthil.sengodan@nokia.com
Hakan Persson hakan.n.persson@telia.se
Sasha Ruditsky sasha@radvision.com
Itamar Gilad itamary@radvision.com
Aki Nienu aki.nienu@nokia.com
Dean Willis dwillis@dynamicsoft.com
Tmima Koren tmima@cisco.com
Brian Williams brian.williams@ericsson.com.au
Gonzalo Camarillo gonalo.comarillo@ericsson.com
Brian Rosen brian.rosen@marconi.com
Francois-Xavier Derome francois-xavier.derome@alcatel.fr
David Bryan dbryan@jasomi.com
Mary Barnes mbarnes@nortelnetworks.com
Mark Watson mwatson@nortelnetworks.com
Markus Isomaki markus.isomaki@nokia.com
Jasminko W. Murlahunc jasminko.w.murlahunc@telia.se
Giuseppe Ricagni Ricagni@nortelnetworks.com
Neil Deason ndeson@ubiquity.net
Laura Mc quzillan mcquillan@logica.com
James Kempf james.kempf@docomo.ubs.usa
Hugh Shieh hugh.shieh@attws.com
Jörg Ott jo@ipdialog.com
Sunil Chotai sunil.cotai@o2.com
Keith Drage drage@lucent.com
Jari Arkko jari.arkko@ericsson.fi
Miguel A. Garcia Miguel.a.garcia@ericsson.com
Xin Chen xchen2@lucent.com
Krisztian Kiss krisztian.kiss@nokia.com
Mark Beckmann mark.beckmann@siemens.com
Georg Mayer georg.mayer@icn.siemens.de
cullen Jennings fluffy@cisco.com
Pekka Pessi pekka.pessi@nokia.com
The meeting first concentrated on security issues and then discussed general requirements from 3GPP to SIP (network initiated call release, etc.).
Security
related issues:
Miguel first presented those slides which were not shown during the main
SIPPING session in the afternoon due to a lack of time. These slides were
mainly based on security.
(1) Extensible authentication
Support for past and future authentication schemes (requirement 6.23.1)
Can AKA also use CHAP for authentication? AKA seems to be a different scheme.
EAP seems to be acceptable.
Dean: Do a two page requirements document for HTTP EAP via SIP and bring it
into SIP.
Should the more specific use of EAP be mentioned in SIP?
EAP can be used as a transport for different authentication mechanisms. AKA will only one of the possible plugins to EAP, i.e. one of the possible authentication mechanisms. Therefore only EAP needs to be supported in SIP.
Jari: This can be seen as different layers. EAP is sort of transport for
different authentication mechanisms. For these mechanisms there should be
specific schemes.
Conlusion: Add HTTP EAP to SIP.
(2) Authentication
Want to avoid extra roundtrips (both INVITE and towards AAA), computation
Initial authentication followed by lower-cost protection for subsequent signaling
Long term keys are stored outside the SIP server
This issue is raised in both security frameworks
Proposal: Authenticate the first SIP message (typically REGISTER) and security association between proxies and UA – Enhanced integrity protection in HTTP diges.
Clarification: This should also work if the first message is not a REGISTER.
Once the UE has been challenged, it can take advantage of it.
This is about application layer authentication.
Initial authentication can generate session keys/kerberos tickets/etc., which then can be used later on. Session keys then are transported to the P-CSCF (=Outbound proxy). Between Home Proxy (S-CSCF) and Outbound Proxy (P-CSCF) there is always a security association. Integrity protection is then done between the UE and the Outbound proxy (first hop) .
What does IETF need to do to make that happen?
Q: What is the protocol to carry keys between S-CSCF and P-CSCF?
A: It should be done by SIP.
So a SIP extension for carrying session keys is needed.
Jonathan: This is a solution for a very specific architecture.
If another protocol for the transport of the session keys is used, then this
will lead to synchronisation problems.
Rohan proposes sending of REGISTER and parallel DIAMETER based
authentication.
Cullen proposes to send DIAMETER before REGISTER from the UA via the P-CSCF to the HSS.
General issue: Split authentication from REGISTER, don’t tunnel DIAMETER.
Jari: Advantage of the 3GPP proposal is that there does not need to be an
AAA infrastructure over the whole network.
As long as this is done only internally of 3GPP it will not harm SIP / IETF
approach. This can be seen as transport of the session keys within EAP (in
the 401 Unauthorized response to the first REGISTER) to the P-CSCF.
Conclusion: Transport Session keys from S-CSCF to P-CSCF within the token
(which can be defined by 3GPP) of the EAP.
(3) Picking security scheme
(6.23.3)
Making SIP aware of security in the path
Digest is vulnerable to MitM (Man in the Middle) attack
SIP has many security methods, how to choose between these
Large, long-lasting deployments can’t switch to new sw/new policy; still want to use new equipment and avoid MitM
Proposals:
NEGOTIATE (does not prevent MitM)
Security agreement: draft-arkko-sip-sec-agree-00.txt
Conclusion: The UA would send all the things it can do and sign that. If
signing the support header is good enough then ok, else we would discuss
better solutions.
Cell-ID:
Cell-ID is needed by the home network, e.g. for location based services (in the home network), location for emergency calls (not in release 5). Cell-ID will be in each initial request.
Jonathan: This is a very general problem, it can be handled by general presence publication, which then can be used also by applications.
Rohan: The 3GPP justification for sending Cell-ID is not enough.
Rohan: No problem to put location information into INVITE, but not for finding the nearest French restaurant.
Brian: If we add a header for each of these requirements, then we will end up with too many headers for services that we already provide by other means (in this case: presence).
Rohan: Cell-ID could be obtained on a per request message.
Sunil: This is too expensive from the point of signalling and processing time (16.000.000 customers in the network which use location services).
Brian: This is a rough location information.
Mark: You need to know if you get a local call, so you need the location information from the other side.
Brian: This is a geopriv subject. Each approach to get location information over the network without approval of geopriv will fail.
Miguel: Location information could also defined as part of Remote-Party-ID, e.g. as tag.
Brian: Having the discussion is very valuable. But passing information between network entities is a valuable request, as long as it does not change the SIP behaviour.
Rohan/others: Such additional information shall be put into the body.
Miguel: This will cause additional overhead as we got multiple MIME parts.
Keith: Getting to the information will cost more (processing) time.
Jonathan: This is still a presence information and not a SIP issue.
Brian: 3GPP should listen to the concerns that IETF has when things like transporting location information via SIP instead of using presence. But if there is a need to have this information for other means, then this can be done by 3GPP specific means.
Conclusion: Cell-ID and other information needed by 3GPP (Visited network ID, charging ID), which does not change the SIP behaviour shall be transported in the body.
Visited Network
Identitifer:
Jonathan: Remote-Party-ID is the authenticated identity which needs to be put in by the authenticator (P-CSCF). So use RPI for that purpose.
As long you have a way to know in the I-CSCF which kind of ipsec connection is coming in, it can provide that information.
Rohan:
Security: put extra token in EAP-Authentication.
Cell-ID, Visited-Network-ID can be tokens in RPI.
Conclusion: Follow Jonathans proposal, i.e. put visited nw id into token of
RPI.
Miguel: According to Jonathan, the
Visited Network Identifier is an "Authenticated" network identity.
It has to be authenticated by the entity that inserts the tag. Jonathan's
proposal was to have a TLS connection between the P-CSCF and the I-CSCF/S-CSCF.
The entity that receives the message over the TLS connection can add the
authenticated network identity to the message.
Charging-ID:
Sunil: Charging-ID is needed for linking charging records which are created by P-CSCF and S-CSCF.
Brian: This can be the Call-ID.
Keith: Charging-ID is also correlation to Bearer-ID/Level.
Jonathan: Media-Authorization header correlates Bearer-Level with session.
Sunil: This is especially done for real-time (pre-paid) charging, when the (expensive) GPRS layer is not charged, as IMS is used, where other charging issues apply.
The 3GPP IMS charging framework is described in 3GPP TS 23.815 (http://www.3gpp.org/ftp/Specs/Latest_drafts/23815-030.zip).
Conclusion: Put Charging ID into the 3GPP specific body, but do further
investigation on this issue when IETF / 3GPP work proceeds, i.e. in release
5.
B2BUA
The network initiated call-release requirement from 3GPP was discussed again. The proposed solution (Proxy sends BYE request in both directions) could only be achieved by a B2BUA. This would regarded as too complex for the IMS entities, at least when strictly following the definitions of the bis Draft. General agreement that so-called “transparent B2BUAs” are allowed from SIP / SIPPING point of view.
Conclusion: 3GPP shall base its solutions on the assumption that transparent
B2BUAs are part of a SIP network. SIP / SIPPING will need to write a short
draft on the general behaviour of such entities.
How to proceed with further requirements
Proposal to bring up those requirements one-by-one on the mailing list,
which were not handled during the ad-hoc. Short summaries (as e.g. Jonathans
discussions of the open issues of the bis draft) should make the mailing
list aware of the problems.