WO2007022800A1 - Procede et dispositif assurant la securite d'acces dans un reseau de communications - Google Patents

Procede et dispositif assurant la securite d'acces dans un reseau de communications Download PDF

Info

Publication number
WO2007022800A1
WO2007022800A1 PCT/EP2005/055136 EP2005055136W WO2007022800A1 WO 2007022800 A1 WO2007022800 A1 WO 2007022800A1 EP 2005055136 W EP2005055136 W EP 2005055136W WO 2007022800 A1 WO2007022800 A1 WO 2007022800A1
Authority
WO
WIPO (PCT)
Prior art keywords
host
certificate
procedure
authorisation
message
Prior art date
Application number
PCT/EP2005/055136
Other languages
English (en)
Inventor
Fredrik Lindholm
Vesa Petteri Lehtovirta
Bengt Olof Sahlin
Jari Juhani Arkko
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Publication of WO2007022800A1 publication Critical patent/WO2007022800A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer

Definitions

  • the present invention relates to a method and apparatus for providing access security in a communications network, for example in an IP Multimedia Subsystem.
  • IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session.
  • the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called "combinational IP Multimedia" services.
  • UMTS Universal Mobile Telecommunications System
  • GSM Global System for Mobile Communications
  • GPRS General Packet Radio Service
  • PDNs packet data networks
  • UMTS is standardised by the 3 rd Generation Partnership Project (3 GPP) which is a conglomeration of regional standards bodies such as the European Telecommunication Standards Institute (ETSI), the Association of Radio Industry Businesses (ARIB) and others.
  • the standardisation of UMTS has progressed in three phases.
  • the first phase is known as Release '99.
  • the Release '99 specifications define the basic architecture that consists of the UMTS Terrestrial Radio Access Network (UTRAN), Circuit Switched Core Network (CS-CN) and Packet Switched Core Network (PS-CN).
  • the release '99 specification offers traditional circuit as well as packet-switched services.
  • the next phase in the standardisation process is Release 4, adding new services to the '99 architecture. Release 5 represents a significant shift, offering both traditional telephony as well as packet-switched services over a single converged packet-based network.
  • the UMTS Release 5 architecture adds a new subsystem known as the IP Multimedia Subsystem (IMS) to the PS-CN for supporting traditional telephony as well as new multimedia services.
  • IMS IP Multimedia Subsystem
  • IMS provides IP Multimedia services over mobile communication networks (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 Releases 5 to 7).
  • IMS provides key features to enrich the end-user person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP- based networks.
  • the IMS is able to connect to both PSTN/ISDN (Public Switched Telephone Network/Integrated Services Digital Network) as well as the Internet.
  • PSTN/ISDN Public Switched Telephone Network/Integrated Services Digital Network
  • the IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers).
  • SIP Session Initiation Protocol
  • SDP Session Description Protocol
  • SIP was created as a user-to- user protocol
  • IMS allows operators and service providers to control user access to services and to charge users accordingly.
  • the 3GPP has chosen SIP for signalling between a User Equipment (UE) and the IMS as well as between the components within the IMS.
  • UE User Equipment
  • FIG. 1 is an illustrative diagram showing a UMTS communications network 200 comprising a User Equipment (UE) 204 located within a Visited Network 202.
  • the UE 204 is attached to a Serving GPRS Support Node (SGSN) 208 via a UTRAN 206, which is in turn in communication with a Gateway GPRS Support Node (GGSN) 210.
  • SGSN Serving GPRS Support Node
  • GGSN Gateway GPRS Support Node
  • the GGSN 210 communicates with a Proxy Call Session Control Function (P-CSCF) 212, which is the first point of contact in the visited IMS network for the UE 204.
  • P-CSCF Proxy Call Session Control Function
  • the P-CSCF 212 forwards SIP registration messages and session establishment messages to the Home Network 214.
  • the first point of contact within the Home Network 214 is the Interrogating Call Session Control Function (I-CSCF) 216, which is an optional node in the IMS architecture, whose main purpose is to query the Home Subscriber Server (HSS) 220 to find the location of the Serving Call Session Control Function (S-CSCF) 218.
  • the S- CSCF 218 performs session management for the IMS network, and there can be several S-CSCFs in the network.
  • the HSS 220 is a centralised subscriber database, and has evolved from the Home Location Register (HLR) from earlier UMTS releases.
  • the HSS 220 interfaces with the I-CSCF and the S-CSCF to provide information about the location of the subscriber and the subscriber's subscription information.
  • the communications network 200 further comprises an application server 222, a database 224 and a mail server 226 located in the Home Network 214. From the S-CSCF 218, signalling messages are passed to the intended destination, which may be another Release 5 IMS network 228 comprising a UE 230, or to a legacy network 232 comprising a PSTN interfaced through a Media Gateway Control Function (MGCF), or to an IP network 234.
  • MGCF Media Gateway Control Function
  • the 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF.
  • P-CSCF Proxy CSCF
  • S-CSCF Serving CSCF
  • I-CSCF Interrogating CSCF
  • a user registers with the IMS using the specified SIP REGISTER method. This is a mechanism for attaching to the IMS and announcing to the IMS the address at which a SIP user identity can be reached.
  • the IMS authenticates the user, and allocates a S-CSCF to that user from the set of available S-CSCFs. Whilst the criteria for allocating S-CSCFs is not specified by 3GPP, these may include load sharing and service requirements. It is noted that the allocation of an S-CSCF is key to controlling (and charging for) user access to IMS- based services. Operators may provide a mechanism for preventing direct user-to-user SIP sessions which would otherwise bypass the S-CSCF.
  • the I-CSCF receives the required S-CSCF capabilities from the home network's Home Subscriber Server (HSS), and selects an appropriate S-CSCF based on the received capabilities.
  • HSS Home Subscriber Server
  • S-CSCF allocation is also carried out for a user by the I-CSCF in the case where the user is called by another party, and the user is not currently allocated an S-CSCF.
  • the P-CSCF is able to forward the request to the selected S-CSCF based on information received from the S- CSCF during the registration process.
  • the Application Servers are for implementing IMS service functionality.
  • Application Servers provide services to end-users in an IMS system, and may be connected either as end-points over the 3GPP defined Mr interface, or "linked in” by an S-CSCF over the 3GPP defined ISC interface.
  • IFC Initial Filter Criteria
  • S-CSCF Session Establishment
  • the IFCs are received by the S-CSCF from an HSS during the IMS registration procedure as part of a user's User Profile.
  • Transport Layer Security with server-side certificates and Digest authentication (see IETF RFC 2246, IETF RFC 2617 and IETF RFC 3261); and either (b) IPsec with IMS AKA authentication (see 3GPP TS 33.203 and also RFC 3310; "AKA” is an abbreviation for "Authentication and Key Agreement”) or (c) Generic Authentication Architeture (GAA) / Generic Bootstrap Architecture (GBA) (see 3GPP TS 33.220 and 3GPP TS 33.222).
  • TLS Transport Layer Security
  • GSA Generic Authentication Architeture
  • GBA Generic Bootstrap Architecture
  • IPsec solution cannot be re-used for environments where NAT traversal is required to be supported, since the current 3GPP IPsec solution does not support NAT traversal.
  • TLS can easily be adopted in such an environment, but even for TLS, certain problems exist.
  • TLS-based access security One of the challenges of a TLS-based access security is when the UE needs to be able to trust the TLS tunnel, i.e. the UE needs to know that the other end of the TLS tunnel is an authorized entity and not a man-in-the-middle that could convey the IMS signalling. This challenge especially arises in IMS where roaming is considered, where the UE establishes the TLS tunnel to the P-CSCF in the visited network, but is present in whatever context TLS is used, for example also when used in the context of the Hypertext Transfer Protocol (HTTP).
  • HTTP Hypertext Transfer Protocol
  • a method of deferring part of a procedure for establishing access security between first and second hosts, and instead incorporating that part into a subsequent procedure involving the first and second hosts, that part being the verification by the first host of a certificate associated with the second host comprising: (a) generating a first authorisation token at the second host using the certificate and at least one cryptographic key derived from a first message sent from a remote server as part of the subsequent procedure; (b) sending the first authorisation token to the first host; (c) generating a second authorisation token at the first host using the certificate and the at least one key according to the same algorithm used to generate the first authorisation token in step (a); and (d) verifying the certificate at the first host if the first and second authorisation tokens agree.
  • Steps (a) and (c) may comprise calculating a Message Authentication Code over the certificate using the at least one key.
  • the Message Authentication Code may be calculated using an HMAC function.
  • the certificate may be a certificate previously sent to the first host by the second host as part of the access security procedure.
  • the certificate may comprise at least one data item requiring verification at the first host as part of the access security procedure.
  • the certificate may comprise only the public key of the second host.
  • the certificate may be a server certificate.
  • the access security may be Transport Layer Security.
  • the access security may be Datagram Transport Layer Security.
  • the access security may be Wireless Transport Layer Security.
  • the method may comprise sending an authorisation verification token from the first host to the second host following positive verification in step (d) to acknowledge receipt and acceptance of the first authorisation token.
  • the method may comprise generating the authorisation verification token at the first host by calculating a Message Authentication Code over the first authorisation token using at least one key.
  • the cryptographic key may be extracted from the first message.
  • Step (b) may comprise appending the first authorisation token to a second message sent to the first host as part of the subsequent procedure.
  • the method may comprise computing the at least one key at the first host for use in step (c) using a third message received as part of the subsequent procedure.
  • the second message may be the same as the third message.
  • the subsequent procedure may be an IP Multimedia Subsystem Authentication and Key Agreement procedure
  • the first host may be a User Equipment
  • the second host may be a Proxy Call Session Control Function
  • the remote server may be a Serving Call Session Control Function
  • the cryptographic key may be a session key
  • the first message may be an authentication challenge message sent towards the first host.
  • the second message may be, or may be equivalent to, the authentication challenge message.
  • the third message may be, or may be equivalent to, the authentication challenge message.
  • the at least one key may comprise a Cipher Key and/or an Integrity Key.
  • the first authorisation token may be forwarded to the User Equipment in step (b) as part of the SM6 message of the subsequent procedure.
  • the authorisation verification token may be sent as part of the SM7 message of the subsequent procedure.
  • the method may comprise removing the authorisation verification token at the Proxy Call Session Control Function before relaying the message to the Serving Call Session Control Function as the SM8 message of the subsequent procedure.
  • the first message may be received at the Proxy Call Session Control Function from the Serving Call Session Control Function by way of the SM4 and SM5 messages of the subsequent procedure.
  • the subsequent procedure may comprise the performance of a data transfer protocol procedure between the first and second hosts and an associated authentication procedure between the second host and the remote server to authenticate the first host, and/or the user of the first host, to the second host.
  • the data transfer protocol may be the Hypertext Transfer Protocol, HTTP.
  • the first host may be a User Equipment and the second host may be an HTTP Proxy.
  • the second message may be, or may be equivalent to, the HTTP Digest authentication challenge message of the subsequent procedure.
  • the third message may be, or may be equivalent to, the HTTP Digest authentication challenge message of the subsequent procedure.
  • the authorisation verification token may be sent as part of the HTTP Digest authentication response message of the subsequent procedure.
  • the at least one key may be provided by the authentication procedure.
  • the first message may be sent as part of the authentication procedure.
  • the authentication procedure may be based on the Generic Authentication Architecture and/or the Generic Bootstrap Architecture.
  • the authentication procedure may be based on the 2G Generic Bootstrap Architecture.
  • the at least one key used by the first host in step (c) may be received at the first host in advance.
  • a system for deferring part of a procedure for establishing access security between first and second hosts, and instead incorporating that part into a subsequent procedure involving the first and second hosts, that part being the verification by the first host of a certificate associated with the second host comprising: means for generating a first authorisation token at the second host using the certificate and at least one cryptographic key derived from a first message sent from a remote server as part of the subsequent procedure; means for sending the first authorisation token to the first host; means for generating a second authorisation token at the first host using the certificate and the at least one key according to the same algorithm used to generate the first authorisation token; and means for verifying the certificate at the first host if the first and second authorisation tokens agree.
  • a third aspect of the present invention there is provided a method, for use by a first host, of deferring part of a procedure for establishing access security between the first host and a second host, and instead incorporating that part into a subsequent procedure involving the first and second hosts, that part being the verification by the first host of a certificate associated with the second host, in which subsequent procedure a first authorisation token is: (a) generated at the second host using the certificate and at least one cryptographic key derived from a first message sent from a remote server as part of the subsequent procedure; and (b) sent to the first host; the method comprising: (c) generating a second authorisation token using the certificate and the at least one key according to the same algorithm used to generate the first authorisation token in step (a); and (d) verifying the certificate if the first and second authorisation tokens agree.
  • a first host operable for deferring part of a procedure for establishing access security between the first host and a second host, and instead incorporating that part into a subsequent procedure involving the first and second hosts, that part being the verification by the first host of a certificate associated with the second host, in which subsequent procedure a first authorisation token is: (a) generated at the second host using the certificate and at least one cryptographic key derived from a first message sent from a remote server as part of the subsequent procedure; and (b) sent to the first host; the first host comprising: means for generating a second authorisation token using the certificate and the at least one key according to the same algorithm used to generate the first authorisation token; and means for verifying the certificate if the first and second authorisation tokens agree.
  • a method for use by a second host, of deferring part of a procedure for establishing access security between a first host and the second host, and instead incorporating that part into a subsequent procedure involving the first and second hosts, that part being the verification by the first host of a certificate associated with the second host, the method comprising: (a) generating a first authorisation token using the certificate and at least one cryptographic key derived from a first message sent from a remote server as part of the subsequent procedure; and (b) sending the first authorisation token to the first host for use by the first host in at least one of: (c) generating a second authorisation token using the certificate and the at least one key according to the same algorithm used to generate the first authorisation token in step (a); and (d) verifying the certificate if the first and second authorisation tokens agree.
  • a second host operable for deferring part of a procedure for establishing access security between a first host and the second host, and instead incorporating that part into a subsequent procedure involving the first and second hosts, that part being the verification by the first host of a certificate associated with the second host, comprising: means for generating a first authorisation token using the certificate and at least one cryptographic key derived from a first message sent from a remote server as part of the subsequent procedure; and means for sending the first authorisation token to the first host for use by the first host in at least one of: (c) generating a second authorisation token using the certificate and the at least one key according to the same algorithm used to generate the first authorisation token; and (d) verifying the certificate if the first and second authorisation tokens agree.
  • an operating program which, when run on an apparatus, causes the apparatus to carry out a method according to the third or fifth aspect of the present invention.
  • an operating program which, when loaded into an apparatus, causes the apparatus to become apparatus according to the fourth or sixth aspect of the present invention.
  • the operating program may be carried on a carrier medium.
  • the carrier medium may be a transmission medium.
  • the carrier medium may be a storage medium.
  • a further aspect of the present invention provides a method of verifying a Proxy Call Session Control Function server certificate at a User Equipment during performance of an IP Multimedia Subsystem Authentication and Key Agreement procedure, comprising: (a) generating a first authorisation token at the Proxy Call Session Control Function using the server certificate and at least one session key extracted from an authentication challenge message sent from a Serving Call Session Control Function towards the User Equipment as part of the procedure; (b) sending the first authorisation token to the User Equipment; (c) computing the at least one session key at the User Equipment using the challenge message received as part of the procedure; (d) generating a second authorisation token at the User Equipment using the server certificate and the at least one session key from step (c) according to the same algorithm used to generate the first authorisation token in step (a); and (e) verifying the server certificate at the User Equipment if the first and second authorisation tokens agree.
  • Steps (a) and (d) may comprise calculating a Message Authentication Code over the server certificate using the at least one session key.
  • the Message Authentication Code may be calculated using an HMAC function.
  • Step (b) may comprise appending the first authorisation token to the challenge message and sending this challenge message to the User Equipment.
  • the first authorisation token may be forwarded to the User Equipment in step (b) as part of the SM6 message of the procedure.
  • the server certificate may comprise only the public key of the Proxy Call Session Control Function.
  • the at least one session key may comprise a Cipher Key.
  • the at least one session key may comprise an Integrity Key.
  • the server certificate may be a server certificate previously sent to the User Equipment by the Proxy Call Session Control Function.
  • the server certificate may comprise at least one data item requiring verification at the User Equipment in the course of setting up access security between the User Equipment and the Proxy Call Session Control Function.
  • the access security may be Transport Layer Security.
  • the access security may be Datagram Transport Layer Security.
  • the access security may be Wireless Transport Layer Security.
  • the method may comprise sending an authorisation verification token from the User Equipment to the Proxy Call Session Control Function following positive verification in step (e) to acknowledge receipt and acceptance of the first authorisation token.
  • the method may comprise generating the authorisation verification token at the User Equipment by calculating a Message Authentication Code over the first authorisation token using at least one session key.
  • the authorisation verification token may be sent as part of the SM7 message of the procedure.
  • the method may comprise removing the authorisation verification token at the Proxy Call Session Control Function before relaying the message to the Serving Call Session Control Function as the SM8 message of the procedure.
  • the authentication challenge message may be received at the Proxy Call Session Control Function from the Serving Call Session Control Function by way of the SM4 and SM5 messages of the procedure.
  • a further aspect of the present invention provides a system for verifying a Proxy Call Session Control Function server certificate at a User Equipment during performance of an IP Multimedia Subsystem Authentication and Key Agreement procedure, comprising: means for generating a first authorisation token at the Proxy Call Session Control Function using the server certificate and at least one session key extracted from an authentication challenge message sent from a Serving Call Session Control Function towards the User Equipment as part of the procedure; means for sending the first authorisation token to the User Equipment; means for computing the at least one session key at the User Equipment using the challenge message received as part of the procedure; means for generating a second authorisation token at the User Equipment using the server certificate and the at least one session key from the computing means according to the same algorithm used to generate the first authorisation token; and means for verifying the server certificate at the User Equipment if the first and second authorisation tokens agree.
  • a further aspect of the present invention provides a method, for use by a User Equipment, of verifying a Proxy Call Session Control Function server certificate during performance of an IP Multimedia Subsystem Authentication and Key Agreement procedure in which a first authorisation token is (a) generated at the Proxy Call Session Control Function using the server certificate and at least one session key extracted from an authentication challenge message sent from a Serving Call Session Control Function towards the User Equipment as part of the procedure and (b) sent to the User Equipment, the method comprising: (c) computing the at least one session key using the challenge message received as part of the procedure; (d) generating a second authorisation token using the server certificate and the at least one session key from step (c) according to the same algorithm used to generate the first authorisation token in step (a); and (e) verifying the server certificate if the first and second authorisation tokens agree.
  • a further aspect of the present invention provides a User Equipment operable to verify a Proxy Call Session Control Function server certificate during performance of an IP Multimedia Subsystem Authentication and Key Agreement procedure in which a first authorisation token is (a) generated at the Proxy Call Session Control Function using the server certificate and at least one session key extracted from an authentication challenge message sent from a Serving Call Session Control Function towards the User Equipment as part of the procedure and (b) sent to the User Equipment, the User Equipment comprising: means for computing the at least one session key using the challenge message received as part of the procedure; means for generating a second authorisation token using the server certificate and the at least one session key from the computing means according to the same algorithm used to generate the first authorisation token; and means for verifying the server certificate if the first and second authorisation tokens agree.
  • a further aspect of the present invention provides a method, for use by a Proxy Call Session Control Function, of allowing verification of a Proxy Call Session Control Function server certificate at a User Equipment during performance of an IP Multimedia Subsystem Authentication and Key Agreement procedure, comprising: (a) generating a first authorisation token using the server certificate and at least one session key extracted from an authentication challenge message sent from a Serving Call Session Control Function towards the User Equipment as part of the procedure; and (b) sending the first authorisation token to the User Equipment for use by the User Equipment in at least one of (c) computing the at least one session key using the challenge message received as part of the procedure; (d) generating a second authorisation token using the server certificate and the at least one session key from step (c) according to the same algorithm used to generate the first authorisation token in step (a); and (e) verifying the server certificate if the first and second authorisation tokens agree.
  • a further aspect of the present invention provides a Proxy Call Session Control Function operable to allow verification of a Proxy Call Session Control Function server certificate at a User Equipment during performance of an IP Multimedia Subsystem Authentication and Key Agreement procedure, comprising: means for generating a first authorisation token using the server certificate and at least one session key extracted from an authentication challenge message sent from a Serving Call Session Control Function towards the User Equipment as part of the procedure; and means for sending the first authorisation token to the User Equipment for use by the User Equipment in at least one of (c) computing the at least one session key using the challenge message received as part of the procedure; (d) generating a second authorisation token using the server certificate and the at least one session key from step (c) according to the same algorithm used to generate the first authorisation token; and (e) verifying the server certificate if the first and second authorisation tokens agree.
  • Figure 1 is a schematic diagram illustrating parts of a UMTS network
  • FIG. 2 illustrates schematically the integration of an IP Multimedia Subsystem into a 3 G mobile communications system
  • Figure 3 illustrates schematically an apparatus and method according to a first embodiment of the present invention
  • Figure 4 illustrates schematically an apparatus and method according to a second embodiment of the present invention
  • Figure 5 illustrates schematically an apparatus and method according to a third embodiment of the present invention.
  • An authentication procedure according to first and second embodiments of the present invention is based on the "IMS AKA” authentication procedure provided by the IMS system, and also makes use of the server certificate.
  • the "IMS AKA” authentication procedure upon which these embodiments of the present invention are based is described in detail in 3GPP TS 33.203 V.6.7.0 (2005-06), and this document and the procedure described therein will be referred to herein as IMSAKA for brevity.
  • the P- CSCF can calculate a Message Authentication Code (MAC) over the server certificate with the keys provided by the IMSAKA procedures. By verifying this MAC, the UE is able to trust the server certificate and the corresponding TLS tunnel. Therefore the MAC can be considered to be an authorisation token.
  • the UE may add an authentication token, assuring the P-CSCF that the UE received the authorisation token from the P-CSCF.
  • a combinational authentication based IMS access security procedure according to the first and second embodiments of the present invention is shown in Figures 3 and 4 respectively (although the interaction with the HSS has been omitted).
  • the IMS registration messages in these embodiments of the present invention are generally the same as shown and described in Section 6.1.1 of IMSAKA, differing in that the authorisation tokens mentioned above are carried in messages SM6 and SM7 respectively. It is also to be noted that it is only the authentication part of IMSAKA that is utilised in these embodiments of the present invention, not the IPsec part.
  • the UE and P-CSCF perform a full TLS handshake.
  • the P-CSCF uses a server certificate for the TLS tunnel.
  • the UE accepts that the certificate is valid without any special verification (for the time being). Note that the UE does not yet know if it can trust this certificate and the corresponding TLS tunnel (as it would have been able to do in a normal TLS session).
  • the UE starts the IMS registration procedure with the SMl message. This message is the same as described in IMSAKA.
  • the P-CSCF relays the IMS registration message in the SM2 message. This message is the same as described in IMSAKA.
  • the S-CSCF sends the authentication challenge, including the cipher key and integrity key CK/IK, as described in IMSAKA.
  • Step S5 The P-CSCF strips off CK/IK from the authentication challenge as described in IMSAKA.
  • the P-CSCF extracts the server certificates from step Sl, and calculates a Message Authentication Code (MAC) over the certificate using the keys CK and/or IK received from the S-CSCF.
  • This MAC can be considered to be a first authorisation token.
  • the MAC can, for example, be performed using the HMAC function (see Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication," RFC 2104, February 1997).
  • the result of the MAC calculation over the certificate (referred to as s token) is appended to the challenge message sent to the UE in Step S6 below.
  • the P-CSCF sends the authentication challenge to the UE in the SM6 message.
  • This message is substantially the same as described in IMSAKA, differing in that it also carries the extra MAC used as the first authorisation token (s token).
  • the UE processes the authentication challenge message as described in IMSAKA, part of which involves computing the session keys CK and IK.
  • the UE uses CK and/or IK to calculate a MAC over the server certificate of the TLS tunnel.
  • the computed MAC can be considered to be a second authorisation token. If the computed MAC equals the MAC received in the authentication challenge (s token) from Step S6 above, then the UE is able to trust the TLS tunnel. If the MAC verification fails, the procedure is aborted.
  • the UE calculates the authentication response and sends it to the P-CSCF in message SM7.
  • the UE may calculate an authorisation verification token (c token) to acknowledge that it received and accepted the s token.
  • the token can be calculated by calculating a MAC (with CK and/or IK as keys) over the received authorisation token (and optionally other authentication parameters received from the P-CSCF).
  • the authentication response message is sent to the P-CSCF and is in general the same as described in IMSAKA, but with the optional addition of the authorisation verification token (c token).
  • the P-CSCF relays the IMS registration message (with the authentication response) in the SM8 message.
  • This message is the same as described in IMSAKA.
  • this token is removed before relaying the message SM8.
  • the c token is also verified by the P-CSCF by calculating a MAC over the same field as the UE did, and then comparing the outcome with the c token. If the verification fails, the procedure is aborted.
  • the S-CSCF sends a 2xx Auth OK message to the P-CSCF in message SMI l.
  • This message is the same as described in IMSAKA.
  • the P-CSCF forwards the 2xx Auth OK towards the UE in SMl 2. This message is the same as described in IMSAKA.
  • the TLS handshake is performed (in step Sl) prior to commencement of the Authentication and Key Agreement phase (starting with step S2).
  • step Sl the TLS handshake procedure
  • Step S7a the TLS handshake procedure of Step Sl of Figure 3
  • Step S7b the session keys CK and IK
  • the only operation that needs to wait until after the TLS handshake procedure is the calculation of the MAC (second authorisation token) over the server certificate of the TLS tunnel, since the server certificate is received in the TLS handshake.
  • a server certificate is used in the generation of the authorisation token s token at the P-CSCF that is verified at the UE.
  • the server certificate in an embodiment of the present invention need not (but could) contain all the information normally associated with a certificate.
  • the server certificate includes only the public key used by the P-CSCF. It would then be enough to communicate only the public key to the UE during the handshake of Step Sl of Figure 3 (Step S7a of Figure 4).
  • a full certificate could be transmitted but with s token being calculated only over the public key part instead of the whole certificate.
  • the term "certificate" or "server certificate” is intended to cover any type of data item or data items requiring verification at the User Equipment in the course of setting up access security between the User Equipment and the Proxy Call Session Control Function.
  • An embodiment of the present invention has several advantages over prior art methods, which can be summarized as follows:
  • TLS instead of IPsec is transparent for the home network and can be used without any special interaction between the visited and home network.
  • the second embodiment has the additional advantage that it can be used with the Security Mechanism Agreement for SIP without the need to first set up a TLS tunnel before the UE and P-CSCF have negotiated it (see 3GPP TS 33.203 and also RFC 3329).
  • an embodiment of the present invention can also be used with the Datagram Transport Layer Security Protocol (which is under specification in IETF, draft-rescorla-dtls-05.txt) as well as the Wireless Transport Layer Security Protocol (WAP-261-WTLS-20010406-a, OMA, available at http://www.openmobilealliance.org/tech/affiliates/wap/wapindex.html).
  • Datagram Transport Layer Security Protocol which is under specification in IETF, draft-rescorla-dtls-05.txt
  • WAP-261-WTLS-20010406-a Wireless Transport Layer Security Protocol
  • Embodiments of the present invention have been described above in relation to parts of a 3GPP IMS network, such as the UE, P-CSCF and S-CSCF. It will be appreciated that an embodiment of the present invention does not require these parts to be exactly as defined in 3GPP in all respects; all that is required is that they comply with the parts of 3GPP that are directly relevant to an embodiment of the present invention.
  • the appended claims are intended to cover a non-3GPP-compliant network and components thereof, irrespective of what those components are normally called.
  • the first and second embodiments of the present invention provide a method of deferring part of a TLS procedure for establishing access security between first and second hosts, and instead incorporating the deferred part into a subsequent IMS AKA procedure involving the first and second hosts, where the deferred part is the verification by the first host of a server certificate associated with the second host.
  • the subsequent procedure to which verification of the server certificate is deferred is an IMS AKA procedure
  • the subsequent procedure comprises the performance of a specified data transfer protocol procedure between the first and second hosts and an associated authentication procedure between the second host and the remote server to authenticate the first host, and/or the user of the first host, to the second host.
  • the data transfer protocol in the third embodiment is the Hypertext Transfer Protocol (HTTP), although the invention is applicable to other data transfer protocols.
  • HTTP Hypertext Transfer Protocol
  • GAA Generic Authentication Architecture
  • GBA Generic Bootstrap Architecture
  • the UE and the HTTP Proxy perform a full TLS handshake.
  • the HTTP Proxy uses a server certificate for the TLS tunnel.
  • the UE accepts that the certificate is valid without any special verification (for the time being). Note that the UE does not yet know if it can trust this certificate and corresponding TLS tunnel (as it would have been able to do in a normal TLS session).
  • the UE sends an HTTP Request (including an identifier for the user) to the HTTP Proxy.
  • the HTTP Proxy starts an authentication procedure to check if there exist any credentials that can be used to authenticate the UE (and/or user of the UE).
  • the HTTP Proxy checks the existence of such credentials by sending an authentication request to one of a number of different sources, depending on the type of authentication procedure being adopted.
  • the following are examples for illustration purposes, and others are possible:
  • the HTTP Proxy could send the 2G authentication request to the HSS/AuC in the case where the HTTP Proxy is acting as a so-called BSF according to GBA (using 2G/GSM authentication vectors).
  • the HTTP Proxy could send the authentication request to a BSF in the case where the HTTP Proxy is acting as a NAF according to GAA/GBA.
  • the HTTP Proxy could send the authentication request to a general AAA in a general scenario where a non 3 G network is used for authentication (according to IETF RFC 2617).
  • the HTTP Proxy could send the authentication request to the HSS in the case where ISIM/USIM based authentication is being used using GBA (with 3G authentication vectors).
  • GAA is essentially an application of GBA. While GBA defines the so-called BSF and the interfaces to it (to the UE, to the HSS, and to the NAF), GAA defines a further part, particularly how the NAF works in practice.
  • GBA is itself split into two parts: "normal” 3G GBA, as used in case (d) above, and 2G GBA (currently described in 3GPP SP-050577, but will be described in the same GBA document TS 33.220 from TS 33.220, v 7.1.0.), as used in case (a) above; these two parts use different types of authentication vectors, with different terminology and so on.).
  • the HTTP Proxy receives one or more authentication keys:
  • the HTTP Proxy receives an authentication vector from the HSS, which is a so-called triplet comprising a Key (Kc), a challenge (Rand), and an expected Response (RES).
  • Kc Key
  • Rand challenge
  • RES expected Response
  • the HTTP Proxy receives an application key (or NAF key) from the BSF.
  • the HTTP Proxy receives a secret key/password (P) for the user (or a derivate of such) that can be used to authenticate the user.
  • P secret key/password
  • the HTTP Proxy receives XRES, RAND, AUTHN and CK/IK in an authentication challenge received from the HSS.
  • the HTTP Proxy extracts the server certificates from step Pl, and calculates a Message Authentication Code (MAC) over the certificate using the keys received in Step P4:
  • MAC Message Authentication Code
  • the HTTP Proxy uses the authentication vector items Kc, Rand, and RES as input values (together with other optionally generated input) to generate an application key.
  • the application key is used to compute a Message Authentication Code (MAC) over the certificate.
  • MAC Message Authentication Code
  • the HTTP Proxy uses the application or NAF key (together with other optional extra input such as the authentication challenge) to calculate a MAC over the certificate.
  • the HTTP Proxy uses the secret key/password (P) to calculate a MAC over the certificate (together with other optional extra input such as the authentication challenge).
  • the HTTP Proxy uses CK and/or IK received from the HSS to calculate a MAC over the certificate.
  • This MAC can be considered to be a first authorisation token.
  • the MAC can, for example, be performed using the HMAC function detailed above.
  • the result of the MAC calculation over the certificate (referred to as s token) is appended to the authentication challenge message sent to the UE in step P6 below.
  • the Proxy sends an HTTP authentication challenge to the UE.
  • the exact parameters may differ depending on authentication method (e.g., GAA/GBA or HTTP Digest authentication according to IETF RFC 2617).
  • This message is generally similar to a normal authentication message, differing in that it also carries the extra MAC used as the first authorisation token (s token).
  • the UE processes the authentication challenge message as it would for a normal authentication request.
  • the UE calculates a MAC over the server certificate of the TLS tunnel, using the same MAC algorithm and key as were used by the HTTP Proxy in step P6:
  • the UE will be able to derive the secret key (Kc) based on the challenge (Rand) received from the HTTP Proxy and the authentication secret stored on the SIM card (Ki). From this it can compute the application key to be used for the MAC calculation over the server certificate.
  • the UE will already have received the NAF key for use in the MAC calculation over the server certificate. It will have received the key after authenticating to a BSF using GBA (3GPP TS 33.220), for example before even the TLS handshake of step Pl.
  • GBA 3GPP TS 33.220
  • the UE processes the authentication challenge message, part of which involves computing the session keys CK and IK.
  • the UE uses CK and/or IK to calculate a MAC over the server certificate. If the computed MAC equals with the MAC received in the authentication challenge (s token), the UE is able to trust the TLS tunnel. If the MAC verification fails, the procedure is aborted.
  • the UE calculates the authentication response and sends it to the HTTP Proxy.
  • the UE may calculate an authorisation verification token (c token) to acknowledge that it received and accepted the s token.
  • the token can be calculated by calculating a MAC (using the appropriate shared key as described above in step P7) over the received authorisation token (and optionally other authentication parameters received from the HTTP Proxy).
  • the authentication response message is sent to the HTTP Proxy and is in general the same as in a normal authentication response, but with the optional addition of the authorisation verification token (c token).
  • the message is authenticated using the normal authentication procedure.
  • a c token is included in step P8
  • the HTTP Proxy verifies the c token by calculating a MAC over the same field as did the UE, and then comparing the outcome with the c token. If the verification fails, the procedure is aborted.
  • the HTTP Proxy may process and/or forward the HTTP request according to normal HTTP procedures.
  • the Proxy replies with a 200 OK message.
  • the third embodiment is therefore very similar to the first embodiment, differing for example in the variety of different ways in which the cryptographic key, used for the MAC calculation at the UE and Proxy respectively, is derived or shared.
  • the same or similar advantages can be achieved with the third embodiment as were described above with reference to the first and second embodiments.
  • operation of one or more of the above-described components can be controlled by a program operating on the device or apparatus.
  • Such an operating program can be stored on a computer-readable medium, or could, for example, be embodied in a signal such as a downloadable data signal provided from an Internet website.
  • the appended claims are to be interpreted as covering an operating program by itself, or as a record on a carrier, or as a signal, or in any other form.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Procédé permettant de différer une partie de procédure d'établissement de sécurité d'accès, du type sécurité de couche de transport (TLS), entre un équipement d'utilisateur (UE) et une fonction de contrôle de session d'appel de mandataire (P-CSCF), et d'incorporer cette partie dans une procédure ultérieure d'authentification de sous-système multimédia IP et d'accord de clé (IMS AKA) faisant intervenir ces équipement UE et fonction P-CSCF. La partie différée est la vérification par l'UE d'un certificat de serveur associé à la fonction P-CSCF. Un premier jeton d'autorisation (s_token) est produit (S5) au niveau de la fonction P-CSCF au moyen du certificat de serveur et d'au moins une clé de session (CK et/ou IK) extraite d'un message de challenge d'authentification (SM5) envoyé (S4) par ladite fonction S-CSCF à l'UE, dans le cadre de la procédure. Le premier jeton d'autorisation (s_token) est destiné (S6, SM6) à l'UE. On détermine (S7) la ou les clés de session (CK et/ou IK) au niveau de l'UE, en utilisant le message de challenge (SM6) reçu dans le cadre de la procédure. Un second jeton d'autorisation est déterminé au niveau de l'UE, sur la base du certificat de serveur et de la ou des clés déterminées (CK et/ou IK), suivant le même algorithme utilisé pour la production du premier jeton d'autorisation (s_token). Le certificat de serveur est vérifié (S7) au niveau de l'UE si les premier et second jetons concordent. On décrit aussi un procédé visant à différer une procédure TLS vers une procédure ultérieure de protocole de transfert d'hypertexte/d'architecture d'authentification générique (GAA)/ d'architecture d'amorce générique (GBA).
PCT/EP2005/055136 2005-08-26 2005-10-10 Procede et dispositif assurant la securite d'acces dans un reseau de communications WO2007022800A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EPPCT/EP2005/054218 2005-08-26
EP2005054218 2005-08-26

Publications (1)

Publication Number Publication Date
WO2007022800A1 true WO2007022800A1 (fr) 2007-03-01

Family

ID=35976695

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2005/055136 WO2007022800A1 (fr) 2005-08-26 2005-10-10 Procede et dispositif assurant la securite d'acces dans un reseau de communications

Country Status (1)

Country Link
WO (1) WO2007022800A1 (fr)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9027111B2 (en) 2010-02-01 2015-05-05 Huawei Technologies Co., Ltd. Relay node authentication method, apparatus, and system
JP2016510527A (ja) * 2013-01-17 2016-04-07 インテル アイピー コーポレイション Ｄａｓｈアウェア・ネットワークアプリケーションファンクション（ｄ−ｎａｆ）
EP3119055A1 (fr) * 2015-07-13 2017-01-18 Vodafone IP Licensing Limited Protocole pour generic bootstrapping architecture (gba)
US9729529B2 (en) 2008-12-31 2017-08-08 Google Technology Holdings LLC Device and method for providing bootstrapped application authentication
CN109120621A (zh) * 2018-08-21 2019-01-01 杭州中天微系统有限公司 数据处理器
CN113992328A (zh) * 2021-10-27 2022-01-28 北京房江湖科技有限公司 零信任传输层流量认证方法、装置及存储介质
WO2022156580A1 (fr) * 2021-01-22 2022-07-28 华为技术有限公司 Procédé d'authentification et appareil de communication
WO2023210952A1 (fr) * 2022-04-28 2023-11-02 삼성전자 주식회사 Système et dispositif d'authentification mutuelle de tls à l'aide d'aka

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020166048A1 (en) * 2001-05-01 2002-11-07 Frank Coulier Use and generation of a session key in a secure socket layer connection

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020166048A1 (en) * 2001-05-01 2002-11-07 Frank Coulier Use and generation of a session key in a secure socket layer connection

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
"Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); 3G security; Access security for IP-based services (3GPP TS 33.203 version 6.7.0 Release 6); ETSI TS 133 203", ETSI STANDARDS, EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE, SOPHIA-ANTIPO, FR, vol. 3-SA3, no. V670, June 2005 (2005-06-01), XP014030761, ISSN: 0000-0001 *
"Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 (Release 7) (3GPP TS 24.229 version 7.0.0 Release 6); ETSI", 3GPP TS 24.229 V7.0.0, XX, XX, June 2005 (2005-06-01), pages 1 - 296, XP002369255 *
DIERKS AND OTHERS T: "RFC 2246 - The TLS Protocol Version 1.0", NETWORK WORKING GROUP REQUEST FOR COMMENTS, XX, XX, 31 January 1999 (1999-01-31), pages 1 - 5,24, XP002333277 *
TORVINEN J ARKKO M NASLUND ERICSSON V: "Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2", IETF STANDARD-WORKING-DRAFT, INTERNET ENGINEERING TASK FORCE, IETF, CH, no. 2, 28 October 2004 (2004-10-28), XP015039773, ISSN: 0000-0004 *

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9729529B2 (en) 2008-12-31 2017-08-08 Google Technology Holdings LLC Device and method for providing bootstrapped application authentication
US9027111B2 (en) 2010-02-01 2015-05-05 Huawei Technologies Co., Ltd. Relay node authentication method, apparatus, and system
US10873579B2 (en) 2013-01-17 2020-12-22 Apple Inc. Dash-aware network application function (D-NAF)
JP2016510527A (ja) * 2013-01-17 2016-04-07 インテル アイピー コーポレイション Ｄａｓｈアウェア・ネットワークアプリケーションファンクション（ｄ−ｎａｆ）
JP2017184260A (ja) * 2013-01-17 2017-10-05 インテル アイピー コーポレイション Ｄａｓｈアウェア・ネットワークアプリケーションファンクション（ｄ−ｎａｆ）
US9906526B2 (en) 2013-01-17 2018-02-27 Intel IP Corporation DASH-aware network application function (D-NAF)
EP3119055A1 (fr) * 2015-07-13 2017-01-18 Vodafone IP Licensing Limited Protocole pour generic bootstrapping architecture (gba)
GB2540354A (en) * 2015-07-13 2017-01-18 Vodafone Ip Licensing Ltd Generci bootstrapping architecture protocol
CN106714154A (zh) * 2015-07-13 2017-05-24 沃达方Ip许可有限公司 通用自举架构协议
US10484869B2 (en) 2015-07-13 2019-11-19 Vodafone Ip Licensing Limited Generic bootstrapping architecture protocol
CN109120621A (zh) * 2018-08-21 2019-01-01 杭州中天微系统有限公司 数据处理器
CN109120621B (zh) * 2018-08-21 2020-11-06 杭州中天微系统有限公司 数据处理器
WO2022156580A1 (fr) * 2021-01-22 2022-07-28 华为技术有限公司 Procédé d'authentification et appareil de communication
CN114884666A (zh) * 2021-01-22 2022-08-09 华为技术有限公司 认证方法及通信装置
CN113992328A (zh) * 2021-10-27 2022-01-28 北京房江湖科技有限公司 零信任传输层流量认证方法、装置及存储介质
WO2023210952A1 (fr) * 2022-04-28 2023-11-02 삼성전자 주식회사 Système et dispositif d'authentification mutuelle de tls à l'aide d'aka

Similar Documents

Publication Publication Date Title
EP1879324B1 (fr) Procede d'authentification d'un terminal utilisateur dans un sous-systeme multimedia ip
KR102456761B1 (ko) 다수의 ims 신원을 인증하기 위한 방법 및 시스템
US8984615B2 (en) Web to IMS registration and authentication for an unmanaged IP client device
US8213901B2 (en) Subscriber identities
US9503890B2 (en) Method and apparatus for delivering keying information
EP1414212B1 (fr) Methode et système pour l'authentification des usagers dans un système de télécommunication
EP1994707B1 (fr) Commande d'accès dans un réseau de communication
US20110004754A1 (en) Method And Apparatuses For Authentication And Reauthentication Of A User With First And Second Authentication Procedures
WO2007022800A1 (fr) Procede et dispositif assurant la securite d'acces dans un reseau de communications
EP1524816B1 (fr) Authentification de messages sur un système de communication
WO2008025280A1 (fr) Procédé et système d'authentification
EP2011299B1 (fr) Methode et appareils de securisation des communications entre un terminal utilisateur et un proxy sip utilisant une association de securite ipsec
EP2449743B1 (fr) Procédé et appareil destinés à être utilisés dans un sous-système multimédia ip
WO2011035579A1 (fr) Procédé, système et terminal d'authentification pour un terminal d'infrastructure d'authentification et de confidentialité de réseau local sans fil (wapi) accédant à un réseau de sous-système ip multimédia (ims)
WO2008089699A1 (fr) Procédé et système d'authentification d'un terminal utilisateur dans un réseau ims
EP1844595B1 (fr) Authentification au moyen d'une fonctionnalité GAA pour connexions de réseau unidirectionnelles
CN112953718B (zh) Ims网络用户的鉴权方法及装置、呼叫会话控制功能实体
Blanchard et al. Wireless security
GB2450096A (en) Network Authentication and Reauthentication
EP1958370A2 (fr) Procede et appareil de distribution d'informations de chiffrement

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 05794752

Country of ref document: EP

Kind code of ref document: A1