3GPP TSG SA WG3 Security S3#23 S May 2002, Victoria, Canada CR-Form-v5.1 CHANGE REQUEST

Size: px

Start display at page:

Download "3GPP TSG SA WG3 Security S3#23 S May 2002, Victoria, Canada CR-Form-v5.1 CHANGE REQUEST"

Mae Antonia Hensley
7 years ago
Views:

1 1 TSG SA WG3 Security S3#23 S My 2002, Victori, Cnd CR-Form-v5.1 CHANGE REQUEST CR CRNum rev - Current version: For HELP on using this form, see bottom of this pge or look t the pop-up text over the symbols. Proposed chnge ffects: (U)SIM ME/UE Rdio Access Network Core Network Title: Source: Support for certifictes Noki Work item code: Dte: 7. My 2002 Ctegory: B Relese: 6 Use one of the following ctegories: Use one of the following releses: F (correction) 2 (GSM Phse 2) A (corresponds to correction in n erlier relese) R96 (Relese 1996) B (ddition of feture), R97 (Relese 1997) C (functionl modifiction of feture) R98 (Relese 1998) D (editoril modifiction) R99 (Relese 1999) Detiled explntions of the bove ctegories cn REL-4 (Relese 4) be found in TR REL-5 (Relese 5) Reson for chnge: Adding feture ccording to the corresponding work item Summry of chnge: Adding the description of the feture in section 5.4; dding the desciption of the corresponding mechnism in section 6.7; dding description of certifictes in Annex D Consequences if not pproved: The plnned feture is not specified. Cluses ffected: 5.4.2, 6.7, Annex D Other specs X Other core specifictions ffected: Test specifictions O&M Specifictions Other comments: 5.4 Appliction security Secure messging between the USIM nd the network USIM Appliction Toolkit, s specified in 3G TS [15], provides the cpbility for opertors or third prty providers to crete pplictions which re resident on the USIM (similr to SIM Appliction Toolkit in GSM). There exists need to secure messges which re trnsferred over the network to pplictions on the USIM, with the level of security chosen by the network opertor or the ppliction provider. Security fetures for USIM Appliction Toolkit re implemented by mens of the mechnisms described ints [7]. These mechnisms ddress the security requirements identified in GSM [16].

2 Void Support for certifictes There exists need for globl scle uthoriztion infrstructure for vrious pplictions nd services. This my be bsed on the system security rchitecture. Mny of these emerging services will be provided by prties tht re not necessrily trusted by the cellulr opertors nor by cellulr subscribers. Therefore technicl mens to del with, nd preferbly minimize, disputes between subscribers nd service providers is necessry. Authoriztion of such services my be bsed on credentils like digitl signtures. The service provider shll use subscriber certifictes in verifying credentils. The UE my lso use certifictes of opertors (opertor certifictes) nd other certifictes issued by opertors in verifying credentils supplied by service providers. The core network shll provide support for issuing certifictes to the UE over the uthenticted network connection between the ME nd the core network. Cluse 6.7 describes mechnisms to provide this support Void Void ****** NEXT MODIFIED SECTION******* Support for delivering certifictes The delivery of certifictes shll be performed s follows. There re two seprte procedures: one for issuing subscriber certificte nd nother for delivering opertor certifictes. Both re run between the UE nd thecn of the visited network. The CN contins the Certifiction Authority (CA) functionlity. The certificte messges re uthenticted becuse they re sent over integrity protected signlling chnnels. Subscriber certifictes issued in this mnner re uthoristion certifictes. They do not necessrily certify identities. UE RAN SGSN CA Request Response Figure 1. Certificte retrievl. In the cse of requesting subscriber certificte, the request shll contin informtion bout wht needs to be certified (e.g., public key). The response shll contin one of the following: subscriber certificte itself, or

3 3 n ddress from which the UE shll obtin the subscriber certificte, or n ddress which the service provider my use in verifying the credentils supplied by UE, or n error messge. In the cse of retrieving the opertor certificte, the request my contin informtion tht explicitly identifies prticulr opertor which my be different from the visited opertor. The response shll contin one of the following: the opertor certificte itself, or informtion needed to verify the opertor certificte, nd n ddress from which the UE shll obtin the opertor certificte, or n error messge. Further detils see nnex D. e use tunderlinedunless nother reference is explicitely specified. McKey()mustmustmust ***** NEXT MODIFIED SECTION ***** Annex D: (normtive) Support for certifictes This nnex defines the certificte relted prmeters used in procedures of cluse 6.7. The following typogrphic convention: Nmes of informtion element fields in protocol messges re bold itlic. Nmes of types re itlic. Optionl fields re mrked (OPTIONAL) Messge prts mrked (CRITICAL) require integrity protection. Messge prts mrked (NON-CRITICAL) do not require integrity protection. See more discussion on this spect below. Definitions of composite types mentioned in this section cn be found in [CERT-FORMAT]. Both protocols re of simple request/response type s shown in cluse 6.7. D.1 Subscriber Certifiction Request: (CRITICAL) key-info: choice of o public key: SubjectPublicKeyInfo (lgorithm identifier, nd bitstring) o pk_hsh: KeyIdentifier (octet string; lgorithm is SHA-1)

4 4 Response: (NON-CRITICAL) D.2 Opertor certificte retrievl o mc_key: octet string. If used, key-origin shll be 3 nd nd cert-info shll be subscriber certificte URL. This is needed if MAC-bsed credentils re used insted of certifictes. key-origin: byte, with e.g. the following reserved vlues o 0 = from UICC, 1 = from nother security module on UE, 2 = from outside UE, 3 = from UE own memory intended-key-usge: Boolen flg describing which usges re proposed, with the following vlues: 0 = utomtic signing llowed 1 = signing with explicit user confirmtion only user-plne-continution-cpbility: Boolen flg. Should be set to true only if the terminl cn ccept continution URL (see the Response definition below). device-certificte: Certificte (OPTIONAL); certificte issued by the mnufcturer of the device where the privte key resides (e.g., smrtcrd). cert-info: choice of o subscriber certificte: Certificte, WAPCertificte [WAPCert] o subscriber certificte URL: URL formtted s specified in [WPKI, section 7.3] from which the certificte cn be retrieved. The UE will give this URL to the verifier insted of its certificte o filure: sequence of ƒ error: byte, with e.g. the following reserved vlues 1. unknown cuse 2. continution requested (continution URL shll be present below) 3. service not vilble (this network does not issue certifictes) 4. service not vilble now (try lter) 5. service not possible without user-plne continution (if terminl indicted user-plne-continution-cpbility=flse) 6. key-origin not cceptble 7. device certificte required (resend certificte request with the device certificte ttched). 8. device certificte invlid (e.g., expired, incorrect, or otherwise invlid) o continution URL: URL (OPTIONAL) When successful response for the subscriber certifiction request is received, UE will find the Issuer Nme of the opertor CA. It cn use this to check if it lredy hs vlid certificte for the opertor CA s public key. If not, it cn initite the opertor certificte retrievl protocol below. A second scenrio for opertor certificte retrievl is when service provider specifies the opertor (by e.g. specifying the hsh of the opertor CA s public key) in ppliction-lyer signlling. In this cse, the UE will know the key hsh of the opertor but my not know the Issuer Nme.

5 5 The opertor certificte retrievl protocol is s follows: Request: (NON-CRITICAL) trget: (OPTIONAL) choice of o Nme. Distinguished nme of the issuing opertor. o KeyIdentifier (octet string, lgorithm is SHA-1) of the opertor CA s public key user-plne-continution-cpbility: Boolen flg indicting if the terminl cn ccept URL of the opertor certificte or not. Response: (CRITICAL) opertor-cert: X.509v3 certificte filure: sequence of o error: byte, with the following reserved vlues 1. unknown cuse 2. no mtching certificte 3. service not vilble now (try lter) opertor cert-info: (OPTIONAL) sequence of 4. service not possible without user-plne continution (if terminl indicted user-plne-continution-cpbility=flse) o hsh: KeyIdentifier (octet string, lgorithm is SHA-1) o url: URL of the opertor certificte D.3 References [CERT-FORMAT] Internet X.509 Public Key Infrstructure Certificte nd CRL Profile, RFC [WAPCert] WAP Certificte nd CRL Profiles, WAP-211-WAPCert, Version 22-My-2001.

6 6

7 7

Network Configuration Independence Mechanism

Network Configuration Independence Mechanism 3GPP TSG SA WG3 Security S3#19 S3-010323 3-6 July, 2001 Newbury, UK Source: Title: Document for: AT&T Wireless Network Configurtion Independence Mechnism Approvl 1 Introduction During the lst S3 meeting