rfc9203v2.txt | rfc9203.txt | |||
---|---|---|---|---|
skipping to change at line 182 ¶ | skipping to change at line 182 ¶ | |||
between the client and AS is RECOMMENDED in this profile, to reduce | between the client and AS is RECOMMENDED in this profile, to reduce | |||
the number of libraries the client has to support, but other | the number of libraries the client has to support, but other | |||
protocols fulfilling the security requirements defined in Section 5 | protocols fulfilling the security requirements defined in Section 5 | |||
of [RFC9200] MAY alternatively be used, such as TLS [RFC8446] or DTLS | of [RFC9200] MAY alternatively be used, such as TLS [RFC8446] or DTLS | |||
[RFC9147]. | [RFC9147]. | |||
Once the client has retrieved the access token, it generates a nonce | Once the client has retrieved the access token, it generates a nonce | |||
N1, as defined in this document (see Section 4.1.1). The client also | N1, as defined in this document (see Section 4.1.1). The client also | |||
generates its own OSCORE Recipient ID, ID1 (see Section 3.1 of | generates its own OSCORE Recipient ID, ID1 (see Section 3.1 of | |||
[RFC8613]), for use with the keying material associated to the RS. | [RFC8613]), for use with the keying material associated to the RS. | |||
The client posts the token N1 and its Recipient ID to the RS using | The client posts the token, N1, and its Recipient ID to the RS using | |||
the authz-info endpoint and mechanisms specified in Section 5.8 of | the authz-info endpoint and mechanisms specified in Section 5.8 of | |||
[RFC9200] and Content-Format = application/ace+cbor. When using this | [RFC9200] and Content-Format = application/ace+cbor. When using this | |||
profile, the communication with the authz-info endpoint is not | profile, the communication with the authz-info endpoint is not | |||
protected, except for the update of access rights. | protected, except for the update of access rights. | |||
If the access token is valid, the RS replies to this request with a | If the access token is valid, the RS replies to this request with a | |||
2.01 (Created) response with Content-Format = application/ace+cbor, | 2.01 (Created) response with Content-Format = application/ace+cbor, | |||
which contains a nonce N2 and its newly generated OSCORE Recipient | which contains a nonce N2 and its newly generated OSCORE Recipient | |||
ID, ID2, for use with the keying material associated to the client. | ID, ID2, for use with the keying material associated to the client. | |||
Moreover, the server concatenates the input salt received in the | Moreover, the server concatenates the input salt received in the | |||
token, N1, and N2 to obtain the Master Salt of the OSCORE security | token, N1, and N2 to obtain the Master Salt of the OSCORE security | |||
context (see Section 3 of [RFC8613]). The RS then derives the | context (see Section 3 of [RFC8613]). The RS then derives the | |||
complete security context associated with the received token from the | complete security context associated with the received token from the | |||
Master Salt; the OSCORE Recipient ID generated by the client (set as | Master Salt; the OSCORE Recipient ID generated by the client (set as | |||
its OSCORE Sender ID); its own OSCORE Recipient ID; plus the | its OSCORE Sender ID); its own OSCORE Recipient ID; plus the | |||
parameters received in the access token from the AS, following | parameters received in the access token from the AS, following | |||
Section 3.2 of [RFC8613]. | Section 3.2 of [RFC8613]. | |||
In a similar way, after receiving the nonce N2, the client | In a similar way, after receiving the nonce N2, the client | |||
concatenates the input salt N1 and N2 to obtain the Master Salt of | concatenates the input salt, N1, and N2 to obtain the Master Salt of | |||
the OSCORE security context. The client then derives the complete | the OSCORE security context. The client then derives the complete | |||
security context from the Master Salt; the OSCORE Recipient ID | security context from the Master Salt; the OSCORE Recipient ID | |||
generated by the RS (set as its OSCORE Sender ID); its own OSCORE | generated by the RS (set as its OSCORE Sender ID); its own OSCORE | |||
Recipient ID; plus the parameters received from the AS. | Recipient ID; plus the parameters received from the AS. | |||
Finally, the client starts the communication with the RS by sending a | Finally, the client starts the communication with the RS by sending a | |||
request protected with OSCORE to the RS. If the request is | request protected with OSCORE to the RS. If the request is | |||
successfully verified, the server stores the complete security | successfully verified, the server stores the complete security | |||
context state that is ready for use in protecting messages and uses | context state that is ready for use in protecting messages and uses | |||
it in the response, and in further communications with the client, | it in the response, and in further communications with the client, | |||
skipping to change at line 339 ¶ | skipping to change at line 339 ¶ | |||
Header: POST (Code=0.02) | Header: POST (Code=0.02) | |||
Uri-Host: "as.example.com" | Uri-Host: "as.example.com" | |||
Uri-Path: "token" | Uri-Path: "token" | |||
Content-Format: application/ace+cbor | Content-Format: application/ace+cbor | |||
Payload: | Payload: | |||
{ | { | |||
/ audience / 5 : "tempSensor4711", | / audience / 5 : "tempSensor4711", | |||
/ scope / 9 : "write", | / scope / 9 : "write", | |||
/ req_cnf / 4 : { | / req_cnf / 4 : { | |||
/ kid / 2 : h'01' | / kid / 3 : h'01' | |||
} | } | |||
} | } | |||
Figure 3: Example C-to-AS POST /token Request for Updating Rights | Figure 3: Example C-to-AS POST /token Request for Updating Rights | |||
to an Access Token Bound to a Symmetric Key | to an Access Token Bound to a Symmetric Key | |||
3.2. AS-to-C: Access Token | 3.2. AS-to-C: Access Token | |||
After verifying the POST request to the token endpoint and that the | After verifying the POST request to the token endpoint and that the | |||
client is authorized to obtain an access token corresponding to its | client is authorized to obtain an access token corresponding to its | |||
skipping to change at line 527 ¶ | skipping to change at line 527 ¶ | |||
Figure 8 shows an example CWT Claims Set that contains the necessary | Figure 8 shows an example CWT Claims Set that contains the necessary | |||
OSCORE parameters in the cnf claim for the update of access rights. | OSCORE parameters in the cnf claim for the update of access rights. | |||
{ | { | |||
/ aud / 3 : "tempSensorInLivingRoom", | / aud / 3 : "tempSensorInLivingRoom", | |||
/ iat / 6 : 1360189224, | / iat / 6 : 1360189224, | |||
/ exp / 4 : 1360289224, | / exp / 4 : 1360289224, | |||
/ scope / 9 : "temperature_h", | / scope / 9 : "temperature_h", | |||
/ cnf / 8 : { | / cnf / 8 : { | |||
/ kid / 2 : h'01' | / kid / 3 : h'01' | |||
} | } | |||
} | } | |||
Figure 8: Example CWT Claims Set with OSCORE Parameters for the | Figure 8: Example CWT Claims Set with OSCORE Parameters for the | |||
Update of Access Rights | Update of Access Rights | |||
3.2.1. The OSCORE_Input_Material | 3.2.1. The OSCORE_Input_Material | |||
An OSCORE_Input_Material is an object that represents the input | An OSCORE_Input_Material is an object that represents the input | |||
material to derive an OSCORE security context, i.e., the local set of | material to derive an OSCORE security context, i.e., the local set of | |||
skipping to change at line 1228 ¶ | skipping to change at line 1228 ¶ | |||
Name: ace_server_recipientid | Name: ace_server_recipientid | |||
CBOR Key: 44 | CBOR Key: 44 | |||
Value Type: bstr | Value Type: bstr | |||
Reference: RFC 9203 | Reference: RFC 9203 | |||
Original Specification: RFC 9203 | Original Specification: RFC 9203 | |||
9.4. OSCORE Security Context Parameters Registry | 9.4. OSCORE Security Context Parameters Registry | |||
IANA has created a new registry entitled "OSCORE Security Context | IANA has created a new registry entitled "OSCORE Security Context | |||
Parameters". The registration procedure depends on range of CBOR | Parameters". The registration procedure depends on the range of CBOR | |||
label values, following [RFC8126]. Guidelines for the experts are | label values, following [RFC8126]. Guidelines for the experts are | |||
provided in Section 9.7. | provided in Section 9.7. | |||
The columns of the registry are: | The columns of the registry are: | |||
Name: The JSON name requested (e.g., "ms"). Because a core goal of | Name: The JSON name requested (e.g., "ms"). Because a core goal of | |||
this document is for the resulting representations to be compact, | this document is for the resulting representations to be compact, | |||
it is RECOMMENDED that the name be short. This name is case | it is RECOMMENDED that the name be short. This name is case | |||
sensitive. Names may not match other registered names in a case- | sensitive. Names may not match other registered names in a case- | |||
insensitive manner unless the designated experts determine that | insensitive manner unless the designated experts determine that | |||
End of changes. 5 change blocks. | ||||
5 lines changed or deleted | 5 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |