Dynamic Symmetric Key Provisioning Protocol (DSKPP)
RFC 6063
| Document | Type | RFC - Proposed Standard (December 2010) Errata | |
|---|---|---|---|
| Authors | Magnus Nyström , Andrea Doherty , Mingliang Pei , Salah Machani | ||
| Last updated | 2020-01-21 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Tim Polk | |
| Send notices to | (None) |
RFC 6063
quot; Id="KC0001">
<pskc:EncryptionKey>
<ds:KeyName>Pre-shared-key-1</ds:KeyName>
</pskc:EncryptionKey>
<pskc:MACMethod
Algorithm=
"http://www.w3.org/2000/09/xmldsig#hmac-sha1">
<pskc:MACKey>
<xenc:EncryptionMethod
Algorithm=
"http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<xenc:CipherData>
<xenc:CipherValue>
2GTTnLwM3I4e5IO5FkufoMUBJBuAf25hARFv0Z7MFk9Ecdb04PWY/qaeCbrgz7Es
</xenc:CipherValue>
</xenc:CipherData>
</pskc:MACKey>
</pskc:MACMethod>
<pskc:KeyPackage>
<pskc:DeviceInfo>
<pskc:Manufacturer>
TokenVendorAcme
</pskc:Manufacturer>
<pskc:SerialNo>
987654321
</pskc:SerialNo>
<pskc:StartDate>
2009-09-01T00:00:00Z
</pskc:StartDate>
<pskc:ExpiryDate>
2014-09-01T00:00:00Z
</pskc:ExpiryDate>
</pskc:DeviceInfo>
<pskc:CryptoModuleInfo>
<pskc:Id>CM_ID_001</pskc:Id>
</pskc:CryptoModuleInfo>
<pskc:Key
Id="MBK000000001"
Doherty, et al. Standards Track [Page 92]
RFC 6063 DSKPP December 2010
Algorithm=
"urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<pskc:Issuer>Example-Issuer</pskc:Issuer>
<pskc:AlgorithmParameters>
<pskc:ResponseFormat Length="6"
Encoding="DECIMAL"/>
</pskc:AlgorithmParameters>
<pskc:Data>
<pskc:Secret>
<pskc:EncryptedValue>
<xenc:EncryptionMethod
Algorithm=
"http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<xenc:CipherData>
<xenc:CipherValue>
oTvo+S22nsmS2Z/RtcoF8AabC6vr
09sh0QIU+E224S96sZjpV+6nFYgn
6525OoepbPnL/fGuuey64WCYXoqh
Tg==
</xenc:CipherValue>
</xenc:CipherData>
</pskc:EncryptedValue>
<pskc:ValueMAC>
o+e9xgMVUbYuZH9UHe0W9dIo88A=
</pskc:ValueMAC>
</pskc:Secret>
<pskc:Counter>
<pskc:PlainValue>0</pskc:PlainValue>
</pskc:Counter>
</pskc:Data>
<pskc:Policy>
<pskc:KeyUsage>OTP</pskc:KeyUsage>
</pskc:Policy>
</pskc:Key>
</pskc:KeyPackage>
</dskpp:KeyContainer>
</dskpp:KeyPackage>
<dskpp:Mac
MacAlgorithm=
"urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256">
l53BmSO6qUzoIgbQegimsKk2es+WRpEl0YFqaOp5PGE=
</dskpp:Mac>
</dskpp:KeyProvServerFinished>
Doherty, et al. Standards Track [Page 93]
RFC 6063 DSKPP December 2010
B.3.3. Example Using the Passphrase-Based Key Wrap Method
The client sends a request similar to that in Appendix B.3.1 with
Authentication Data based on an Authentication Code, and the server
responds using the Passphrase-Based Key Wrap method to encrypt the
provisioning key (note that the encryption is derived from the
password component of the Authentication Code). The Authentication
Data is set in clear text when it is sent over a secure transport
channel such as TLS [RFC5246].
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<dskpp:KeyProvClientHello
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
Version="1.0">
<dskpp:DeviceIdentifierData>
<dskpp:DeviceId>
<pskc:Manufacturer>TokenVendorAcme</pskc:Manufacturer>
<pskc:SerialNo>987654321</pskc:SerialNo>
<pskc:StartDate>2009-09-01T00:00:00Z</pskc:StartDate>
<pskc:ExpiryDate>2014-09-01T00:00:00Z</pskc:ExpiryDate>
</dskpp:DeviceId>
</dskpp:DeviceIdentifierData>
<dskpp:SupportedKeyTypes>
<dskpp:Algorithm>
urn:ietf:params:xml:ns:keyprov:pskc:hotp
</dskpp:Algorithm>
<dskpp:Algorithm>
http://www.rsa.com/rsalabs/otps/schemas/2005/09/otps-wst#SecurID-AES
</dskpp:Algorithm>
</dskpp:SupportedKeyTypes>
<dskpp:SupportedEncryptionAlgorithms>
<dskpp:Algorithm>
http://www.w3.org/2001/04/xmlenc#rsa_1_5
</dskpp:Algorithm>
</dskpp:SupportedEncryptionAlgorithms>
<dskpp:SupportedMacAlgorithms>
<dskpp:Algorithm>
urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256
</dskpp:Algorithm>
</dskpp:SupportedMacAlgorithms>
<dskpp:SupportedProtocolVariants>
<dskpp:TwoPass>
<dskpp:SupportedKeyProtectionMethod>
urn:ietf:params:xml:schema:keyprov:dskpp:passphrase-wrap
</dskpp:SupportedKeyProtectionMethod>
Doherty, et al. Standards Track [Page 94]
RFC 6063 DSKPP December 2010
<dskpp:Payload>
<ds:KeyInfo>
<ds:KeyName>Passphrase-1</ds:KeyName>
</ds:KeyInfo>
</dskpp:Payload>
</dskpp:TwoPass>
</dskpp:SupportedProtocolVariants>
<dskpp:SupportedKeyPackages>
<dskpp:KeyPackageFormat>
urn:ietf:params:xml:ns:keyprov:dskpp:pskc-key-container
</dskpp:KeyPackageFormat>
</dskpp:SupportedKeyPackages>
<dskpp:AuthenticationData>
<dskpp:ClientID>AC00000A</dskpp:ClientID>
<dskpp:AuthenticationCodeMac>
<dskpp:Nonce>
ESIzRFVmd4iZqrvM3e7/ESIzRFVmd4iZqrvM3e7/ESI=
</dskpp:Nonce>
<dskpp:IterationCount>1</dskpp:IterationCount>
<dskpp:Mac
MacAlgorithm=
"urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256">
K4YvLMN6Q1DZvtShoCxQag==
</dskpp:Mac>
</dskpp:AuthenticationCodeMac>
</dskpp:AuthenticationData>
</dskpp:KeyProvClientHello>
In this example, the server responds to the previous request by
returning a key package in which the provisioning key was encrypted
using the Passphrase-Based Key Wrap key protection method.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<dskpp:KeyProvServerFinished
xmlns:pskc="urn:ietf:params:xml:ns:keyprov:pskc"
xmlns:dskpp="urn:ietf:params:xml:ns:keyprov:dskpp"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:dkey="http://www.w3.org/2009/xmlsec-derivedkey#"
xmlns:pkcs5=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"
Version="1.0"
Status="Success"
SessionID="4114">
<dskpp:KeyPackage>
<dskpp:KeyContainer Version="1.0" Id="KC0002">
<pskc:EncryptionKey>
<dkey:DerivedKey>
Doherty, et al. Standards Track [Page 95]
RFC 6063 DSKPP December 2010
<dkey:KeyDerivationMethod
Algorithm=
"http://www.rsasecurity.com/rsalabs/pkcs/schemas/
pkcs-5v2-0#pbkdf2">
<pkcs5:PBKDF2-params>
<Salt>
<Specified>Ej7/PEpyEpw=</Specified>
</Salt>
<IterationCount>1000</IterationCount>
<KeyLength>16</KeyLength>
</pkcs5:PBKDF2-params>
</dkey:KeyDerivationMethod>
<xenc:ReferenceList>
<xenc:DataReference URI="#ED"/>
</xenc:ReferenceList>
<dkey:MasterKeyName>
Passphrase1
</dkey:MasterKeyName>
</dkey:DerivedKey>
</pskc:EncryptionKey>
<pskc:MACMethod
Algorithm=
"http://www.w3.org/2000/09/xmldsig#hmac-sha1">
<pskc:MACKey>
<xenc:EncryptionMethod
Algorithm=
"http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<xenc:CipherData>
<xenc:CipherValue>
2GTTnLwM3I4e5IO5FkufoOEiOhNj91fhKRQBtBJYluUDsPOLTfUvoU2dStyOwYZx
</xenc:CipherValue>
</xenc:CipherData>
</pskc:MACKey>
</pskc:MACMethod>
<pskc:KeyPackage>
<pskc:DeviceInfo>
<pskc:Manufacturer>
TokenVendorAcme
</pskc:Manufacturer>
<pskc:SerialNo>
987654321
</pskc:SerialNo>
<pskc:StartDate>
2009-09-01T00:00:00Z
</pskc:StartDate>
<pskc:ExpiryDate>
2014-09-01T00:00:00Z
</pskc:ExpiryDate>
Doherty, et al. Standards Track [Page 96]
RFC 6063 DSKPP December 2010
</pskc:DeviceInfo>
<pskc:CryptoModuleInfo>
<pskc:Id>CM_ID_001</pskc:Id>
</pskc:CryptoModuleInfo>
<pskc:Key
Id="MBK000000001"
Algorithm=
"urn:ietf:params:xml:ns:keyprov:pskc:hotp">
<pskc:Issuer>Example-Issuer</pskc:Issuer>
<pskc:AlgorithmParameters>
<pskc:ResponseFormat Length="6"
Encoding="DECIMAL"/>
</pskc:AlgorithmParameters>
<pskc:Data>
<pskc:Secret>
<pskc:EncryptedValue>
<xenc:EncryptionMethod
Algorithm=
"http://www.w3.org/2001/04/
xmlenc#aes128-cbc"/>
<xenc:CipherData>
<xenc:CipherValue>
oTvo+S22nsmS2Z/RtcoF8HX385uMWgJ
myIFMESBmcvtHQXp/6T1TgCS9CsgKtm
cOrF8VoK254tZKnrAjiD5cdw==
</xenc:CipherValue>
</xenc:CipherData>
</pskc:EncryptedValue>
<pskc:ValueMAC>
pbgEbVYxoYs0x41wdeC7eDRbUEk=
</pskc:ValueMAC>
</pskc:Secret>
<pskc:Counter>
<pskc:PlainValue>0</pskc:PlainValue>
</pskc:Counter>
</pskc:Data>
<pskc:Policy>
<pskc:KeyUsage>OTP</pskc:KeyUsage>
</pskc:Policy>
</pskc:Key>
</pskc:KeyPackage>
</dskpp:KeyContainer>
</dskpp:KeyPackage>
<dskpp:Mac MacAlgorithm=
"urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256">
Jc4VsNODYXgfbDmTn9qQZgcL3cKoa//j/NRT7sTpKOM=
</dskpp:Mac>
</dskpp:KeyProvServerFinished>
Doherty, et al. Standards Track [Page 97]
RFC 6063 DSKPP December 2010
Appendix C. Integration with PKCS #11
A DSKPP Client that needs to communicate with a connected
cryptographic module to perform a DSKPP exchange MAY use PKCS #11
[PKCS-11] as a programming interface as described herein. This
appendix forms an informative part of the document.
C.1. The Four-Pass Variant
When performing four-pass DSKPP with a cryptographic module using the
PKCS #11 programming interface, the procedure described in
[CT-KIP-P11], Appendix B, is RECOMMENDED.
C.2. The Two-Pass Variant
A suggested procedure to perform two-pass DSKPP with a cryptographic
module through the PKCS #11 interface using the mechanisms defined in
[CT-KIP-P11] is as follows:
a. On the client side,
1. The client selects a suitable slot and token (e.g., through
use of the <DeviceIdentifier> or the <PlatformInfo> element
of the DSKPP trigger message).
2. A nonce R is generated, e.g., by calling C_SeedRandom and
C_GenerateRandom.
3. The client sends its first message to the server, including
the nonce R.
b. On the server side,
1. A generic key K_PROV = K_TOKEN | K_MAC (where '|' denotes
concatenation) is generated, e.g., by calling C_GenerateKey
(using key type CKK_GENERIC_SECRET). The template for K_PROV
MUST allow it to be exported (but only in wrapped form, i.e.,
CKA_SENSITIVE MUST be set to CK_TRUE and CKA_EXTRACTABLE MUST
also be set to CK_TRUE), and also to be used for further key
derivation. From K, a token key K_TOKEN of suitable type is
derived by calling C_DeriveKey using the PKCS #11 mechanism
CKM_EXTRACT_KEY_FROM_KEY and setting the CK_EXTRACT_PARAMS to
the first bit of the generic secret key (i.e., set to 0).
Likewise, a MAC key K_MAC is derived from K_PROV by calling
C_DeriveKey using the CKM_EXTRACT_KEY_FROM_KEY mechanism,
this time setting CK_EXTRACT_PARAMS to the length of K_PROV
(in bits) divided by two.
Doherty, et al. Standards Track [Page 98]
RFC 6063 DSKPP December 2010
2. The server wraps K_PROV with either the public key of the
DSKPP Client or device, the pre-shared secret key, or the
derived shared secret key by using C_WrapKey. If use of the
DSKPP key wrap algorithm has been negotiated, then the
CKM_KIP_WRAP mechanism MUST be used to wrap K. When calling
C_WrapKey, the hKey handle in the CK_KIP_PARAMS structure
MUST be set to NULL_PTR. The pSeed parameter in the
CK_KIP_PARAMS structure MUST point to the nonce R provided by
the DSKPP Client, and the ulSeedLen parameter MUST indicate
the length of R. The hWrappingKey parameter in the call to
C_WrapKey MUST be set to refer to the key wrapping key.
3. Next, the server needs to calculate a MAC using K_MAC. If
use of the DSKPP MAC algorithm has been negotiated, then the
MAC is calculated by calling C_SignInit with the CKM_KIP_MAC
mechanism followed by a call to C_Sign. In the call to
C_SignInit, K_MAC MUST be the signature key, the hKey
parameter in the CK_KIP_PARAMS structure MUST be set to
NULL_PTR, the pSeed parameter of the CT_KIP_PARAMS structure
MUST be set to NULL_PTR, and the ulSeedLen parameter MUST be
set to zero. In the call to C_Sign, the pData parameter MUST
be set to the concatenation of the string ServerID and the
nonce R, and the ulDataLen parameter MUST be set to the
length of the concatenated string. The desired length of the
MAC MUST be specified through the pulSignatureLen parameter
and MUST be set to the length of R.
4. If the server also needs to authenticate its message (due to
an existing K_TOKEN being replaced), the server MUST
calculate a second MAC. Again, if use of the DSKPP MAC
algorithm has been negotiated, then the MAC is calculated by
calling C_SignInit with the CKM_KIP_MAC mechanism followed by
a call to C_Sign. In this call to C_SignInit, the K_MAC'
existing before this DSKPP run MUST be the signature key (the
implementation may specify K_MAC' to be the value of the
K_TOKEN that is being replaced, or a version of K_MAC from
the previous protocol run), the hKey parameter in the
CK_KIP_PARAMS structure MUST be set to NULL, the pSeed
parameter of the CT_KIP_PARAMS structure MUST be set to
NULL_PTR, and the ulSeedLen parameter MUST be set to zero.
In the call to C_Sign, the pData parameter MUST be set to the
concatenation of the string ServerID and the nonce R, and the
ulDataLen parameter MUST be set to the length of concatenated
string. The desired length of the MAC MUST be specified
through the pulSignatureLen parameter and MUST be set to the
length of R.
Doherty, et al. Standards Track [Page 99]
RFC 6063 DSKPP December 2010
5. The server sends its message to the client, including the
wrapped key K_TOKEN, the MAC and possibly also the
authenticating MAC.
c. On the client side,
1. The client calls C_UnwrapKey to receive a handle to K. After
this, the client calls C_DeriveKey twice: once to derive
K_TOKEN and once to derive K_MAC. The client MUST use the
same mechanism (CKM_EXTRACT_KEY_FROM_KEY) and the same
mechanism parameters as used by the server above. When
calling C_UnwrapKey and C_DeriveKey, the pTemplate parameter
MUST be used to set additional key attributes in accordance
with local policy and as negotiated and expressed in the
protocol. In particular, the value of the <KeyID> element in
the server's response message MAY be used as CKA_ID for
K_TOKEN. The key K_PROV MUST be destroyed after deriving
K_TOKEN and K_MAC.
2. The MAC is verified in a reciprocal fashion as it was
generated by the server. If use of the CKM_KIP_MAC mechanism
has been negotiated, then in the call to C_VerifyInit, the
hKey parameter in the CK_KIP_PARAMS structure MUST be set to
NULL_PTR, the pSeed parameter MUST be set to NULL_PTR, and
ulSeedLen MUST be set to 0. The hKey parameter of
C_VerifyInit MUST refer to K_MAC. In the call to C_Verify,
pData MUST be set to the concatenation of the string ServerID
and the nonce R, and the ulDataLen parameter MUST be set to
the length of the concatenated string, pSignature to the MAC
value received from the server, and ulSignatureLen to the
length of the MAC. If the MAC does not verify the protocol
session ends with a failure. The token MUST be constructed
to not "commit" to the new K_TOKEN or the new K_MAC unless
the MAC verifies.
3. If an authenticating MAC was received (REQUIRED if the new
K_TOKEN will replace an existing key on the token), then it
is verified in a similar vein but using the K_MAC' associated
with this server and existing before the protocol run (the
implementation may specify K_MAC' to be the value of the
K_TOKEN that is being replaced, or a version of K_MAC from
the previous protocol run). Again, if the MAC does not
verify the protocol session ends with a failure, and the
token MUST be constructed not to "commit" to the new K_TOKEN
or the new K_MAC unless the MAC verifies.
Doherty, et al. Standards Track [Page 100]
RFC 6063 DSKPP December 2010
Appendix D. Example of DSKPP-PRF Realizations
D.1. Introduction
This example appendix defines DSKPP-PRF in terms of AES [FIPS197-AES]
and HMAC [RFC2104]. This appendix forms a normative part of the
document.
D.2. DSKPP-PRF-AES
D.2.1. Identification
For cryptographic modules supporting this realization of DSKPP-PRF,
the following URN MUST be used to identify this algorithm in DSKPP:
urn:ietf:params:xml:ns:keyprov:dskpp:prf-aes-128
When this URN is used to identify the encryption algorithm, the
method for encryption of R_C values described in Section 4.2.4 MUST
be used.
D.2.2. Definition
DSKPP-PRF-AES (k, s, dsLen)
Input:
k Encryption key to use
s Octet string consisting of randomizing material. The
length of the string s is sLen.
dsLen Desired length of the output
Output:
DS A pseudorandom string, dsLen-octets long
Steps:
1. Let bLen be the output block size of AES in octets:
bLen = (AES output block length in octets)
(normally, bLen = 16)
2. If dsLen > (2**32 - 1) * bLen, output "derived data too long" and
stop
Doherty, et al. Standards Track [Page 101]
RFC 6063 DSKPP December 2010
3. Let n be the number of bLen-octet blocks in the output data,
rounding up, and let j be the number of octets in the last block:
n = CEILING( dsLen / bLen)
j = dsLen - (n - 1) * bLen
4. For each block of the pseudorandom string DS, apply the function
F defined below to the key k, the string s and the block index to
compute the block:
B1 = F (k, s, 1) ,
B2 = F (k, s, 2) ,
...
Bn = F (k, s, n)
The function F is defined in terms of the CMAC construction from
[NIST-SP800-38B], using AES as the block cipher:
F (k, s, i) = CMAC-AES (k, INT (i) || s)
where INT (i) is a four-octet encoding of the integer i, most
significant octet first, and the output length of CMAC is set to
bLen.
Concatenate the blocks and extract the first dsLen octets to produce
the desired data string DS:
DS = B1 || B2 || ... || Bn<0..j-1>
Output the derived data DS.
D.2.3. Example
If we assume that dsLen = 16, then:
n = 16 / 16 = 1
j = 16 - (1 - 1) * 16 = 16
DS = B1 = F (k, s, 1) = CMAC-AES (k, INT (1) || s)
Doherty, et al. Standards Track [Page 102]
RFC 6063 DSKPP December 2010
D.3. DSKPP-PRF-SHA256
D.3.1. Identification
For cryptographic modules supporting this realization of DSKPP-PRF,
the following URN MUST be used to identify this algorithm in DSKPP:
urn:ietf:params:xml:ns:keyprov:dskpp:prf-sha256
When this URN is used to identify the encryption algorithm to use,
the method for encryption of R_C values described in Section 4.2.4
MUST be used.
D.3.2. Definition
DSKPP-PRF-SHA256 (k, s, dsLen)
Input:
k Encryption key to use
s Octet string consisting of randomizing material. The
length of the string s is sLen.
dsLen Desired length of the output
Output:
DS A pseudorandom string, dsLen-octets long
Steps:
1. Let bLen be the output size of SHA-256 in octets of [FIPS180-SHA]
(no truncation is done on the HMAC output):
bLen = 32
(normally, bLen = 16)
2. If dsLen > (2**32 - 1) * bLen, output "derived data too long" and
stop
3. Let n be the number of bLen-octet blocks in the output data,
rounding up, and let j be the number of octets in the last block:
n = CEILING( dsLen / bLen)
j = dsLen - (n - 1) * bLen
4. For each block of the pseudorandom string DS, apply the function
F defined below to the key k, the string s and the block index to
compute the block:
Doherty, et al. Standards Track [Page 103]
RFC 6063 DSKPP December 2010
B1 = F (k, s, 1),
B2 = F (k, s, 2),
...
Bn = F (k, s, n)
The function F is defined in terms of the HMAC construction from
[RFC2104], using SHA-256 as the digest algorithm:
F (k, s, i) = HMAC-SHA256 (k, INT (i) || s)
where INT (i) is a four-octet encoding of the integer i, most
significant octet first, and the output length of HMAC is set to
bLen.
Concatenate the blocks and extract the first dsLen octets to produce
the desired data string DS:
DS = B1 || B2 || ... || Bn<0..j-1>
Output the derived data DS.
D.3.3. Example
If we assume that sLen = 256 (two 128-octet long values) and dsLen =
16, then:
n = CEILING( 16 / 32 ) = 1
j = 16 - (1 - 1) * 32 = 16
B1 = F (k, s, 1) = HMAC-SHA256 (k, INT (1) || s)
DS = B1<0 ... 15>
That is, the result will be the first 16 octets of the HMAC output.
Doherty, et al. Standards Track [Page 104]
RFC 6063 DSKPP December 2010
Authors' Addresses
Andrea Doherty
RSA, The Security Division of EMC
174 Middlesex Turnpike
Bedford, MA 01730
USA
EMail: andrea.doherty@rsa.com
Mingliang Pei
VeriSign, Inc.
487 E. Middlefield Road
Mountain View, CA 94043
USA
EMail: mpei@verisign.com
Salah Machani
Diversinet Corp.
2225 Sheppard Avenue East, Suite 1801
Toronto, Ontario M2J 5C2
Canada
EMail: smachani@diversinet.com
Magnus Nystrom
Microsoft Corp.
One Microsoft Way
Redmond, WA 98052
USA
EMail: mnystrom@microsoft.com
Doherty, et al. Standards Track [Page 105]