B.2 Generic key derivation function

33.2203GPPGeneric Authentication Architecture (GAA)Generic Bootstrapping Architecture (GBA)TS

B.2.0 General

The input parameters and their lengths shall be concatenated into a string S as follows:

1. The length of each input parameter measured in octets shall be encoded into a two octet-long string:

a) express the number of octets in input parameter Pi as a number k in the range [0, 65535].

b) Li is then a 16-bit long encoding of the number k, encoded as described in clause B.2.1.

2. String S shall be constructed from n+1 input parameters as follows:

S = FC || P0 || L0 || P1 || L1 || P2 || L2 || P3 || L3 ||… || Pn || Ln

where

FC is used to distinguish between different instances of the algorithm and is either a single octet or consists of two octets of the form FC1|| FC2 where FC1 = 0xFF and FC2 is a single octet,

P0 … Pn are the n+1 input parameter encodings, and

L0 … Ln are the two-octet representations of the length of the corresponding input parameter encodings P0.. Pn.

In this specification the following restriction applies to P0: P0 is a static ASCII-encoded string.

This restriction is not part of the KDF definition and does not apply to the KDF when used by other 3GPP specifications unless explicitly stated so in those specifications.

3. The final output, i.e. the derived key is equal to the KDF computed on the string S using the key, denoted Key. The present document defines the following KDF:

derived key = HMAC-SHA-256 ( Key , S )

as specified in [22] and [23].

B.2.1 Input parameter encoding

B.2.1.1 General

This clause specifies how encodings of different data types is to be done. Encoding rules for further data types may be added in future releases if needed.

B.2.1.2 Character string encoding

A character string shall be encoded to an octet string according to UTF-8 encoding rules as specified in IETF RFC 3629 [24] and apply Normalization Form KC (NFKC) as specified in [37].

B.2.1.3 Non-negative integer encoding

A non-negative integer value j, which is input to the KDF, shall be encoded into the octet string Pi as follows:

1) Encode j in base 2.

2) Let n be number of bits as defined for this input parameter in 3GPP specifications, or, if undefined elsewhere, let n be the least multiple of 8 that is greater or equal to the number of bits of the base 2 encoding of j

3) Create an octet string such that the least significant bit of the octet string shall be equal to the least significant bit of j written in base 2, the second to least significant bit of the octet string shall be equal to the second to least significant bit of j written in base 2 and so on (according to clause 3.4 of this specification). If the number of bits in j written in base 2 is less than n, the remaining most significant bits in the octet string shall be set to zero; if the number of bits in j written in base 2 is equal to n, there is no need for such zero padding.

The encoding Li of the number k of octets in Pi follows the above rule.

EXAMPLE1: If Pi is Uplink NAS COUNT then the number k of octets in Pi is 4, according to TS 33.401, Annex A, and n = 32. Assume that Uplink NAS COUNT has the integer value j = 259. Then the base 2 encoding of 259 is 100000011,  and Pi consists of the octet string 0000000 0000000 00000001 00000011, or 0x00 0x00 0x01 0x03 in hex representation, and Li consists of the octet string 0000000 00000100, or 0x00 0x04 in hex representation.

EXAMPLE2: If the length of Pi is undefined elsewhere, and the integer value j = 259 is to be encoded into the parameter Pi then the base 2 encoding of 259 is 100000011,  n and hence the length of parameter Pi in bits is 16, the number k of octets in Pi is 2, and Pi consists of the octet string 00000001 00000011, or 0x01 0x03 in hex representation, and Li consists of the octet string 0000000 00000010, or 0x00 0x02 in hex representation.

B.2.2 FC value allocations

FC values shall only be assigned to a key derivation function by their allocated specification.

FC values in the range 0x00 – 0x0F are allocated for use in this specification.

FC values in the range 0x10 – 0x1F are allocated for use in TS 33.401 [35].

FC values in the range 0x20 – 0x2F are allocated for use in TS 33.402 [36].

FC values in the range 0x30 – 0x37 are allocated for use in TS 33.102 [2].

FC values in the range 0x38 – 0x3F are allocated for use in TS 43.020 [47].

FC values in the range 0x40 – 0x47 are allocated for use in TS 33.224 [39].

FC values in the range 0x48 – 0x4F are allocated for use in TS 33.303 [49].

FC values in the range 0x50 – 0x57 are allocated for use in TS 33.179 [50].

FC values in the range 0x50 – 0x57 are also allocated for use in TS 33.180 [54].

FC values in the range 0x58 – 0x5F are allocated for use in TS 33.203 [51].

FC values in the range 0x60 – 0x68 are allocated for use in TS 33.163 [52].

FC values in the ranges 0x69 – 0x79, 0x7B – 0x7D and 0x83-0x84 are allocated for use in TS 33. 501 [53].

FC value 0x7A is allocated for use in TS 33.122 [55].

FC values in the range 0x7E – 0x7F are allocated for use in TS 33.536 [56].

FC values in the range 0x80 – 0x82 are allocated for use in TS 33.535 [58].

FC values in the range 0x85 – 0x8B are allocated for use in TS 33.503 [67].

FC values in the range 0x85 – 0xDF are reserved for future use in 3GPP specifications.

FC values in the range 0xE0 – 0xEF are reserved for uses of the KDF by other standardization organisations where the FC value for such use is registered in the present specification.

FC values in the range 0xF0 – 0xFE are reserved for proprietary uses of the KDF where the FC value for the such use is not registered with 3GPP.

FC values of the form 0xFF || FC2 are reserved for future use in 3GPP specifications.

NOTE 1: Registering an FC value with 3GPP for use by other standardization organisations means that only the FC value is recorded in the present specification, but the full specification of the key derivation is done elsewhere. This has the advantage that clashes in FC values in different uses by other standardization organisations can be avoided. On the other hand, not registering an FC value with 3GPP for proprietary use means that 3GPP may have no knowledge of this use at all.

NOTE 2: Ranges of FC values for use by other standardization organisations or for proprietary use could be extended in the future if such a need was indicated to 3GPP.