A.2 Procedures
24.4823GPPMission Critical Services (MCS) identity managementProtocol specificationRelease 17TS
A.2.1 HTTP client
A.2.1.1 General
The HTTP client in the UE shall support the client role defined in IETF RFC 7230 [23].
A.2.1.2 HTTP client in UE
The HTTP client in the UE shall support the client role defined in IETF RFC 2818 [10].
The HTTP client in the UE shall support transport layer security (TLS) as specified in 3GPP TS 33.180 [17].
The HTTP client in the UE is configured with the following parameters:
1) a home HTTP proxy FQDN;
2) a home HTTP proxy port;
3) a TLS tunnel authentication method. The TLS tunnel authentication method parameter is set to one of the following:
a) one-way authentication of the HTTP proxy based on the server certificate;
b) mutual authentication based on certificates; and
c) mutual authentication based on pre-shared key;
as specified in 3GPP TS 33.180 [17];
4) if the TLS tunnel authentication method is the mutual authentication based on certificates:
a) TLS tunnel authentication X.509 certificate; and
5) if the TLS tunnel authentication method is the mutual authentication based on pre-shared key;
a) TLS tunnel authentication pre-shared key.
The HTTP client in the UE shall establish a TCP connection towards the home HTTP proxy FQDN and the home HTTP proxy port, unless the specific TCP connection is to be used for the IdM client to IdM server procedures described in subclause 6.2 and subclause 6.3 in the present document, in which case the HTTP client shall establish a TCP connection towards the IdM server.
The HTTP client in the UE shall establish a TLS tunnel via the TCP connection as specified in 3GPP TS 33.180 [17]. When establishing the TLS tunnel, the HTTP client in the UE shall act as a TLS client and the UE shall perform the TLS tunnel authentication using the TLS authentication method indicated by the TLS tunnel authentication method parameter according to 3GPP TS 33.180 [17]. The UE shall use the configured TLS tunnel authentication X.509 certificate and the configured TLS tunnel authentication pre-shared key when applicable for the used TLS authentication method. In order to prevent man-in-the-middle attacks, the HTTP client in the UE shall check the home HTTP proxy FQDN against the server’s identity as presented in the received server’s certificate message if the TCP connection terminates on the HTTP proxy. The HTTP client in the UE shall not check the portion of dereferenced HTTP URL against the server’s identity as presented in the received server’s certificate message if the TCP connection terminates on the HTTP proxy, but shall do so if the TCP connection terminates on the IdM server.
NOTE: The TLS tunnel can be terminated in the HTTP proxy (rather than in the HTTP server providing the dereferenced HTTP URL).
The HTTP client in the UE shall send and receive all HTTP messages via the TLS tunnel.
If the HTTP client in the UE has an access token of the "bearer" token type as specified in IETF RFC 6750 [14], the HTTP client in the UE shall include an Authorization header field with the "Bearer" authentication scheme as specified in IETF RFC 6750 [14] in HTTP requests.
A.2.1.3 HTTP client in network entity
The HTTP client in the network entity is configured with the following parameters:
1) a home HTTP proxy FQDN; and
2) a home HTTP proxy port.
The HTTP client in the network entity shall send and receive all HTTP messages via the home HTTP proxy.
The HTTP client in the network entity shall insert an X-3GPP-Asserted-Identity header field as specified in 3GPP TS 24.109 [15] in the HTTP request and shall set X-3GPP-Asserted-Identity header field to the identity of the HTTP client in the network entity. The identity of the HTTP client in the network entity can be a public service identity, an MC service group ID, or an MC service ID.
A.2.2 HTTP proxy
A.2.2.1 General
The HTTP proxy shall support proxy role of IETF RFC 7230 [23].
A.2.2.2 HTTP request method from HTTP client in UE
The HTTP proxy shall support the server role of IETF RFC 7230 [23], and IETF RFC 2818 [10].
The HTTP proxy shall support transport layer security (TLS) as specified in 3GPP TS 33.180 [17].
The HTTP proxy is configured with the following HTTP proxy parameters:
1) an FQDN of an HTTP proxy for UEs; and
2) a TCP port of an HTTP proxy for UEs.
The HTTP proxy shall support establishing TCP connections on the FQDN of HTTP proxy for UEs and the TCP port of HTTP proxy for UEs. The HTTP proxy shall support establishing a TLS tunnel via each such TCP connection as specified in 3GPP TS 33.180 [17]. When establishing the TLS tunnel, the HTTP proxy shall act as TLS server.
Upon reception of an HTTP request method via a TLS tunnel:
1) if the HTTP request method contains an X-3GPP-Asserted-Identity header field as specified in 3GPP TS 24.109 [15], the HTTP proxy shall reject the HTTP request method with an HTTP 403 (Forbidden) response and do not continue with rest of the steps;
2) if the HTTP request method contains a Request-URI identifying a resource in a partner’s MC serviceprovider, the HTTP proxy shall forward the HTTP request method according to the Request-URI; and
3) if an HTTP request method contains a Request-URI identifying a resource in own MC service provider, the HTTP proxy shall act as reverse proxy for the HTTP request method and shall forward the HTTP request method according to the MCPTT provider policy.
A.2.2.3 HTTP request method from HTTP client in network entity within trust domain
The HTTP proxy is configured with the following parameters:
1) a FQDN of an HTTP proxy for trusted entities; and
2) a TCP port of an HTTP proxy for trusted entities.
Upon receiving an HTTP request method via a TCP connection established on the FQDN of HTTP proxy for UEs and the TCP port of HTTP proxy for UEs, if the TCP connection is between network elements within trusted domain as specified in 3GPP TS 33.180 [17]:
1) if the HTTP request method contains a Request-URI identifying a resource in a partner’s MC service provider, the HTTP proxy shall forward the HTTP request method according to the Request-URI; and
2) if an HTTP request method contains Request-URI identifying a resource in own MC service provider, the HTTP proxy shall act as reverse proxy for the HTTP request method and shall forward the HTTP request method according to MC service provider policy.
A.2.3 HTTP server
The HTTP server shall support the server role of IETF RFC 7230 [23].
Upon reception of an HTTP request:
1) if the received HTTP request does not contain an Authorization header field with the "Bearer" authentication scheme and a bearer access token as specified in IETF RFC 6750 [14] and the received HTTP request does not contain an X-3GPP-Asserted-Identity header field as specified in 3GPP TS 24.109 [15], the HTTP server shall reject the request with HTTP 403 (Forbidden) response;
2) if the received HTTP request contains an Authorization header field with the "Bearer" authentication scheme and a bearer access token as specified in IETF RFC 6750 [14];
a) the HTTP server shall validate the bearer access token as specified in IETF RFC 6750 [14]; and
b) the HTTP server shall consider the MC service ID derived from the bearer access token as the identity of the sender of the HTTP request; and
3) if the received HTTP request does not contain an Authorization header field with the "Bearer" authentication scheme and a bearer access token as specified in IETF RFC 6750 [14] and the received HTTP request contains an X-3GPP-Asserted-Identity header field as specified in 3GPP TS 24.109 [15], the HTTP server shall consider the URI in the X-3GPP-Asserted-Identity header field as the identity of the sender of the HTTP request.
Annex B (informative):
Change history
|
Change history |
|||||||
|
Date |
TSG # |
TSG Doc. |
CR |
Rev |
Subject/Comment |
Old |
New |
|
2015-07 |
Initial proposal to CT1#92-bis |
– |
0.0.0 |
||||
|
2015-08 |
Contains the following agreed P-CRs from CT1#92-bis: C1ah-150013, C1ah-150033 Minor alignments by the rapporteur. |
0.0.0 |
0.1.0 |
||||
|
2015-09 |
Updated to include specification number after CT#69 allocation. |
0.1.0 |
0.1.1 |
||||
|
2016-02 |
Contains the following agreed P-CRs from CT1-on MCPTT: C1ah-160030, C1ah-160105, C1ah-160103, C1ah-160088 |
0.1.1 |
0.2.0 |
||||
|
2016-02 |
Contains the following agreed P-CRs from CT1#96: C1-161040, C1-161222, C1-161228, C1-161229, C1-161260, C1-161300, C1-161301, C1-161388 |
0.2.0 |
0.3.0 |
||||
|
2016-03 |
CT-71 |
CP-160055 |
Version 1.0.0 created for presentation for information and approval |
0.3.0 |
1.0.0 |
||
|
2016-03 |
CT-71 |
Version 13.0.0 created after approval |
1.0.0 |
13.0.0 |
|||
|
2016-03 |
CT-71 |
Minor editorial changes by TS rapporteur |
13.0.0 |
13.0.1 |
|||
|
2016-06 |
CT-72 |
CP-160322 |
0001 |
1 |
Corrections for HTTP server authenticating HTTP client |
13.0.1 |
13.1.0 |
|
2016-06 |
CT-72 |
CP-160322 |
0002 |
User authentication procedure corrections |
13.0.1 |
13.1.0 |
|
|
2016-06 |
CT-72 |
CP-160322 |
0003 |
Correction of IdM client to IdM server interface |
13.0.1 |
13.1.0 |
|
|
2016-12 |
CT#74 |
Change of spec number from 24.382 to 24.482 with wider scope and changed title |
24.382 |
24.482 |
|||
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2016-12 |
CT-74 |
CP-160733 |
0005 |
F |
Identity Management endpoint correction (this was a CR to 24.382) |
13.2.0 |
|
|
2017-03 |
CT-75 |
CP-170053 |
0002 |
F |
Scope TS naming adaptation for R13 24.482 |
13.3.0 |
|
|
2017-03 |
CT-75 |
CP-170127 |
0001 |
F |
Modifying references in TS 24.482 to cater for rel-14 Stage 2 and Stage 3 mission critical restructure |
14.0.0 |
|
|
2017-06 |
CT-76 |
CP-171114 |
0003 |
1 |
B |
Updating subclause 4.1 for multi MC service applicability |
14.1.0 |
|
2017-06 |
CT-76 |
CP-171114 |
0004 |
1 |
B |
Security stage 2 reference change, additional definitions and abbreviations for R14 IdM |
14.1.0 |
|
2017-06 |
CT-76 |
CP-171114 |
0005 |
1 |
B |
Updated Entities subclauses for IdM |
14.1.0 |
|
2017-06 |
CT-76 |
CP-171114 |
0006 |
1 |
B |
Updated client procedures for IdM |
14.1.0 |
|
2017-06 |
CT-76 |
CP-171114 |
0007 |
2 |
B |
Updated server procedures for IdM |
14.1.0 |
|
2017-06 |
CT-76 |
CP-171114 |
0008 |
1 |
B |
Updated clause 7 and Annex A for IdM |
14.1.0 |
|
2017-06 |
CT-76 |
CP-171114 |
0009 |
2 |
B |
Addition of token exchange procedures |
14.1.0 |
|
2017-09 |
CT-77 |
CP-172101 |
0010 |
F |
Token exchange corrections |
14.2.0 |
|
|
2017-09 |
CT-77 |
CP-172101 |
0011 |
F |
Subclause 4.1 updates and reference corrections |
14.2.0 |
|
|
2018-03 |
CT-79 |
CP-180072 |
0012 |
1 |
F |
Correction to Identity Management Token Exchange procedures |
14.3.0 |
|
2018-06 |
SA-80 |
– |
– |
– |
Update to Rel-15 version (MCC) |
15.0.0 |
|
|
2020-06 |
CT-88e |
CP-201087 |
-0014 |
1- |
A |
draft-ietf-oauth-token-exchange has been published as RFC8693 |
15.1.0 |
|
2020-07 |
SA-88e |
– |
– |
– |
Update to Rel-16 version (MCC) |
16.0.0 |
|
|
2021-12 |
CT#94e |
CP-213031 |
0015 |
B |
Reference update for HTTP/1.1 protocol |
17.0.0 |
|
|
2022-03 |
CT#95e |
CP-220276 |
0016 |
– |
F |
Fix oauth reference |
17.1.0 |