Hi,
I apology for taking too long to review the document. Overall I think it is
in good shape but I do have some minor comments on the current version. I
have not been through the IANA section, I assumed it has already been
validated by IANA. Please find my comments below.
Once fixed, I do not expect any action from my p[art on the datatracker and
expect the draft to move forward almost by itself.
Yours,
Daniel
OSCORE Profile of the Authentication and Authorization for Constrained
Environments Framework
draft-ietf-ace-oscore-profile-14
[...]
2. Protocol Overview
This section gives an overview of how to use the ACE Framework
[I-D.ietf-ace-oauth-authz] to secure the communication between a
client and a resource server using OSCORE [RFC8613]. The parameters
needed by the client to negotiate the use of this profile with the
authorization server, as well as the OSCORE setup process, are
described in detail in the following sections.
The RS maintains a collection of OSCORE Security Contexts with
associated authorization information for all the clients that it is
communicating with. The authorization information is maintained as
policy that is used as input to processing requests from those
clients.
This profile requires a client to retrieve an access token from the
AS for the resource it wants to access on an RS, by sending an access
token request to the token endpoint, as specified in section 5.6 of
[I-D.ietf-ace-oauth-authz]. The access token request and response
MUST be confidentiality-protected and ensure authenticity. This
profile RECOMMENDS the use of OSCORE between client and AS, but other
protocols (such as TLS or DTLS) can be used as well.
<mglt>
I usually expect a recommendation to be
motivated. In this case, the recommendation
seems to be motivated by not having two
different libraries - OSCORE and TLSvXs as
opposed to taking of some properties that
OSCORE have as opposed to DTLS. I believe the
motivation should be explicitly stated.
I believe that the RECOMMMENDation comes to
fill the section 5.8.1
draft-ietf-ace-oauth-authz. I believe the
text should mention that such recommendation
is one attribute that needs to be completed
by the profile. This is mostly to avoid the
recommendation to be considered as anecdotal
or a comment.
It seems that SHOULD would make it more
normative than a RECOMMEND. But that is only
a personal though.
</mglt>
Once the client has retrieved the access token, it generates a nonce
N1. The client also generates its OSCORE Recipient ID (see
Section 3.1 of [RFC8613]), ID1,
<mglt>
I believe that ID1 is the Recipient ID. I am
wondering if the text "OSCORE Recipient ID
ID1 (see Section 3.1... )" would not be
clearer. Though this might be clarified by
the RFC editor.
I believe "its" should be clarified
especially in the overview section to expose
that the Recipient ID is being used by the
client to associate the received messages. In
other words, the RS will use this ID ( as
Sender ID) when sending responses to the
client.
The reason is more that I believe the
overview section should provide a description
that is understandable for people that may
not be fully aware of the details of OSCORE
or that have not yet read the document. In my
case - belonging to these two categories - I
found the detailed section clearer than the
overview. This is just to clarify my
intention.
I have the impression that N1 is specific to
this profile. In other words, it is not
generated for the oauth-authz (Client-Nonce)
nor for OSCORE. One difficulty of these
profiles is that they have to put the glue
between the protocol OSCORE and the ACE
framework oauth-auth. It would maybe ease
the reading to specify what is in the profile
and what is being defined outside. I have
the impression that the implicit convention
you are using in the protocol overview
section is that by default what is being
mentioned is defined by the profile and what
is being defined outside the profile is being
explicitly referenced. It might worth
stating that rule - at least in the overview
section.
This is at least clarified in the detailed
sections.
</mglt>
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 authz-info endpoint and mechanisms
specified in section 5.8 of [I-D.ietf-ace-oauth-authz] and Content-
Format = application/ace+cbor. When using this profile, the
communication with the authz-info endpoint is not protected, except
for update of access rights.
If the access token is valid, the RS replies to this request with a
2.01 (Created) response with Content-Format = application/ace+cbor,
which contains a nonce N2 and its newly generated OSCORE Recipient
ID, ID2, for use with the keying material associated to the client.
Moreover, the server concatenates the input salt received in the
token, N1, and N2 to obtain the Master Salt of the OSCORE Security
Context (see section 3 of [RFC8613]). The RS then derives the
complete Security Context associated with the received token from the
Master Salt, the OSCORE Recipient ID generated by the client (set as
Palombini, et al. Expires June 17, 2021 [Page 4]
Internet-Draft OSCORE Profile of ACE December 2020
its OSCORE Sender ID), its own OSCORE Recipient ID, plus the
parameters received in the access token from the AS, following
section 3.2 of [RFC8613].
In a similar way, after receiving the nonce N2, the client
concatenates the input salt, N1 and N2 to obtain the Master Salt of
the OSCORE Security Context. The client then derives the complete
Security Context from the Master Salt, the OSCORE Recipient ID
generated by the RS (set as its OSCORE Sender ID), its own OSCORE
Recipient ID, plus the parameters received from the AS.
Finally, the client sends a request protected with OSCORE to the RS.
<mglt>
It is unclear it that request is the
communication between the client and the RS
or something in the ace framework or oscore.
</mglt>
If the request is successfully verified, the server stores the
complete Security Context state that is ready for use in protecting
messages, and uses it in the response, and in further communications
with the client, until token deletion, due to e.g. expiration. This
Security Context is discarded when a token (whether the same or a
different one) is used to successfully derive a new Security Context
for that client.
The use of random nonces during the exchange prevents the reuse of an
Authenticated Encryption with Associated Data (AEAD) nonces/key pair
for two different messages. Two-time pad might otherwise occur when
<mglt>
I am wondering if two time pad is correct as
opposed to a collision. I might be wrong but
two time pad seems to be correlated to OTP. I
see this closer to IV collision than OTP.
Unless you are very sure to be correct, I
would suggest to use collision instead.
</mglt>
client and RS derive a new Security Context from an existing (non-
expired) access token, as might occur when either party has just
rebooted. Instead, by using random nonces as part of the Master
Salt, the request to the authz-info endpoint posting the same token
results in a different Security Context, by OSCORE construction,
since even though the Master Secret, Sender ID and Recipient ID are
the same, the Master Salt is different (see Section 3.2.1 of
[RFC8613]). Therefore, the main requirement for the nonces is that
they have a good amount of randomness. If random nonces were not
used, a node re-using a non-expired old token would be susceptible to
on-path attackers provoking the creation of OSCORE messages using old
AEAD keys and nonces.
<mglt>
I might be missing something, but my
understanding of the text above is that
nonces MUST NOT repeat and I do not see the
necessity for nonce to be non predictable.
Typically would we have an issue using an
incrementing nonce that is persistent to
reboot.
I think the cryptographic properties should
be clearly mentioned and maybe separated from
the implementation recommendation.
</mglt>
After the whole message exchange has taken place, the client can
contact the AS to request an update of its access rights, sending a
similar request to the token endpoint that also includes an
identifier so that the AS can find the correct OSCORE security input
material it has previously shared with the client. This specific
identifier, encoded as a byte string, is assigned by the AS to be
unique in the sets of its OSCORE security input materials, and is not
used as input material to derive the full OSCORE Security Context.
An overview of the profile flow for the OSCORE profile is given in
Figure 1. The names of messages coincide with those of
[I-D.ietf-ace-oauth-authz] when applicable.
Palombini, et al. Expires June 17, 2021 [Page 5]
Internet-Draft OSCORE Profile of ACE December 2020
C RS AS
| | |
| ----- POST /token ----------------------------> |
| | |
| <---------------------------- Access Token ----- |
| + Access Information |
| ---- POST /authz-info ---> | |
| (access_token, N1, ID1) | |
| | |
| <- 2.01 Created (N2, ID2)- | |
| | |
/Sec Context /Sec Context |
derivation/ derivation/ |
| | |
| ---- OSCORE Request -----> | |
| | |
| /proof-of-possession |
| Sec Context storage/ |
| | |
| <--- OSCORE Response ----- | |
| | |
/proof-of-possession | |
Sec Context storage/ | |
| | |
| ---- OSCORE Request -----> | |
| | |
| <--- OSCORE Response ----- | |
| | |
/mutual ... | |
authentication/
Figure 1: Protocol Overview
<mglt>
The figure is very clarifying, and though
this might be a very personal nit I would
have found it clearer to have the figure
before the explanatory text.
</mglt>
3.1. C-to-AS: POST to token endpoint
[...]
Header: POST (Code=0.02)
Uri-Host: "as.example.com"
Uri-Path: "token"
Content-Format: "application/ace+cbor"
Payload:
{
"req_aud" : "tempSensor4711",
"scope" : "write",
"req_cnf" : {
"kid" : h'01'
}
<mglt>
For my comprehension, the kid seems to me an
id to the security context. Though this is
an example, I am a bit surprised the value is
01, which look small. So I am just willing
to check my understanding.
</mglt>
Figure 3: Example C-to-AS POST /token request for updating rights to
an access token bound to a symmetric key.
3.2. AS-to-C: Access Token
After verifying the POST request to the token endpoint and that the
client is authorized to obtain an access token corresponding to its
access token request, the AS responds as defined in section 5.6.2 of
[I-D.ietf-ace-oauth-authz]. If the client request was invalid, or
not authorized, the AS returns an error response as described in
section 5.6.3 of [I-D.ietf-ace-oauth-authz].
The AS can signal that the use of OSCORE is REQUIRED for a specific
access token by including the "profile" parameter with the value
"coap_oscore" in the access token response. This means that the
client MUST use OSCORE towards all resource servers for which this
access token is valid, and follow Section 4.3 to derive the security
context to run OSCORE. Usually it is assumed that constrained
devices will be pre-configured with the necessary profile, so that
this kind of profile signaling can be omitted.
<mglt>
The AS may indicate the type of communication
between the client and the RS. However, it
seems to me the client does not provides the
AS the capabilities (i.e. supported
profiles), which makes for example impossible
to the AS to pick one that fits the client.
I also have the impression the AS cannot
provide multiple available profiles and let
the client pick one that is implemented. As
a result, the coap_oscore seems to be here to
indicate a "limitation" associated to the RS
- in this case OSCORE is mandatory.
While I agree that in pre-configuration
environment may things can be pre-agreed, I
am reading the text above as making the
specification of the profile as almost
useless. I am wondering if we could not
instead mention that an AS willing to
indicate the use of OSCORE SHOULD set the
profile parameter to "coap_oscore". A client
receiving such value and supporting this
profile SHOULD use this profile. The
motivation for setting the profile may be
that OSCORE is only supported or that there
is a preference to use OSCORE.
</mglt>
Moreover, the AS MUST send the following data:
o a master secret
o an identifier of the OSCORE Input Material
Additionally, the AS MAY send the following data, in the same
response.
o a context identifier
o an AEAD algorithm
o an HMAC-based key derivation function (HKDF) algorithm
Palombini, et al. Expires June 17, 2021 [Page 8]
Internet-Draft OSCORE Profile of ACE December 2020
o a salt
o the OSCORE version number
This data is transported in the OSCORE_Input_Material. The
OSCORE_Input_Material is a CBOR map object, defined in Section 3.2.1.
This object is transported in the 'cnf' parameter of the access token
response as defined in Section 3.2 of [I-D.ietf-ace-oauth-params], as
the value of a field named 'osc', registered in Section 9.5 and
Section 9.6.
The AS MAY assign an identifier to the context (context identifier).
This identifier is used as ID Context in the OSCORE context as
described in section 3.1 of [RFC8613]. If assigned, this parameters
MUST be communicated as the 'contextId' field in the
OSCORE_Input_Material. The applications needs to consider that this
identifier is sent in the clear and may reveal information about the
endpoints, as mentioned in section 12.8 of [RFC8613].
<mglt>
It is unclear to me why such contextId is
needed. I suspect - but I am not sure - this
could be used as a reference for the AS of a
Context established between the client and
the RS. In such case I assume the context ID
(kid) is only shared by the client and the RS
so it could not be used for example when a
token needs to be updated /renewed.
I am wondering if that is correct and I
believe motivation for such id should be
clarified.
</mglt>
The master secret and the identifier of the OSCORE_Input_Material
MUST be communicated as the 'ms' and 'id' field in the 'osc' field in
the 'cnf' parameeter of the access token response. If included, the
AEAD algorithm is sent in the 'alg' parameter in the
OSCORE_Input_Material; the HKDF algorithm in the 'hkdf' parameter of
the OSCORE_Input_Material; a salt in the 'salt' parameter of the
OSCORE_Input_Material; and the OSCORE version in the 'version'
parameter of the OSCORE_Input_Material.
The same parameters MUST be included in the claims associated with
the access token. This profile RECOMMENDS the use of CBOR web token
(CWT) as specified in [RFC8392]. If the token is a CWT, the same
OSCORE_Input_Material structure defined above MUST be placed in the
'osc' field of the 'cnf' claim of this token.
The AS MUST send different OSCORE_Input_Material (and therefore
different access tokens) to different authorized clients, in order
for the RS to differentiate between clients.
Figure 4 shows an example of an AS response, with payload in CBOR
diagnostic notation without the tag and value abbreviations. The
access token has been truncated for readability.
Palombini, et al. Expires June 17, 2021 [Page 9]
Internet-Draft OSCORE Profile of ACE December 2020
Header: Created (Code=2.01)
Content-Type: "application/ace+cbor"
Payload:
{
"access_token" : h'8343a1010aa2044c53 ...
(remainder of access token (CWT) omitted for brevity)',
"profile" : "coap_oscore",
"expires_in" : "3600",
"cnf" : {
"osc" : {
"id" : h'01',
"ms" : h'f9af838368e353e78888e1426bd94e6f'
}
}
}
Figure 4: Example AS-to-C Access Token response with OSCORE profile.
Figure 5 shows an example CWT Claims Set, including the relevant
OSCORE parameters in the 'cnf' claim, in CBOR diagnostic notation
without tag and value abbreviations.
{
"aud" : "tempSensorInLivingRoom",
"iat" : "1360189224",
"exp" : "1360289224",
"scope" : "temperature_g firmware_p",
"cnf" : {
"osc" : {
"ms" : h'f9af838368e353e78888e1426bd94e6f',
"id" : h'01'
}
}
}
Figure 5: Example CWT Claims Set with OSCORE parameters.
The same CWT Claims Set as in Figure 5, using the value abbreviations
defined in [I-D.ietf-ace-oauth-authz] and [RFC8747] and encoded in
CBOR is shown in Figure 6. The bytes in hexadecimal are reported in
the first column, while their corresponding CBOR meaning is reported
after the '#' sign on the second column, for easiness of readability.
<mglt>
Just for my understanding. Figure 5 shows an
"access_token". I am wondering if that is
possible that some parameters may be in the
CWT but not mentioned in clear (to the
client) in the AS-to-C Access Token response.
In my mind, I see the CWT as being encrypted
so the client is not expected to interpret
it. Is that correct ?
</mglt>
[...]
3.2.1. The OSCORE_Input_Material
id: This parameter identifies the OSCORE_Input_Material and is
encoded as a byte string. In JSON, the "id" value is a Base64
encoded byte string. In CBOR, the "id" type is byte string, and
has label 8.
version: This parameter identifies the OSCORE Version number, which
is an unsigned integer. For more information about this field,
Palombini, et al. Expires June 17, 2021 [Page 13]
Internet-Draft OSCORE Profile of ACE December 2020
see section 5.4 of [RFC8613]. In JSON, the "version" value is an
integer. In CBOR, the "version" type is integer, and has label 0.
ms: This parameter identifies the OSCORE Master Secret value, which
is a byte string. For more information about this field, see
section 3.1 of [RFC8613]. In JSON, the "ms" value is a Base64
encoded byte string. In CBOR, the "ms" type is byte string, and
has label 1.
hkdf: This parameter identifies the OSCORE HKDF Algorithm. For more
information about this field, see section 3.1 of [RFC8613]. The
values used MUST be registered in the IANA "COSE Algorithms"
registry (see [COSE.Algorithms]) and MUST be HMAC-based HKDF
algorithms. The value can either be the integer or the text
string value of the HMAC-based HKDF algorithm in the "COSE
Algorithms" registry. In JSON, the "hkdf" value is a case-
sensitive ASCII string or an integer. In CBOR, the "hkdf" type is
text string or integer, and has label 4.
alg: This parameter identifies the OSCORE AEAD Algorithm. For more
information about this field, see section 3.1 of [RFC8613] The
values used MUST be registered in the IANA "COSE Algorithms"
registry (see [COSE.Algorithms]) and MUST be AEAD algorithms. The
value can either be the integer or the text string value of the
HMAC-based HKDF algorithm in the "COSE Algorithms" registry. In
JSON, the "alg" value is a case-sensitive ASCII string or an
integer. In CBOR, the "alg" type is text string or integer, and
has label 5.
salt: This parameter identifies an input to the OSCORE Master Salt
value, which is a byte string. For more information about this
field, see section 3.1 of [RFC8613]. In JSON, the "salt" value is
a Base64 encoded byte string. In CBOR, the "salt" type is byte
string, and has label 6.
contextId: This parameter identifies the security context as a byte
string. This identifier is used as OSCORE ID Context. For more
information about this field, see section 3.1 of [RFC8613]. In
JSON, the "contextID" value is a Base64 encoded byte string. In
CBOR, the "contextID" type is byte string, and has label 7.
<mglt>
I am wondering if there is any kind of
overlap between the id and contextId. They
do represent different objects, but if Input
generate a single Security Context, it seems
to me that both designates the same OSCORE
communication. I am thus wondering why do we
need these two ids.
</mglt>
[...]
4. Client-RS Communication
The following subsections describe the details of the POST request
and response to the authz-info endpoint between client and RS. The
client generates a nonce N1 and an identifier ID1 unique in the sets
of its own Recipient IDs, and posts them together with the token that
includes the materials (e.g., OSCORE parameters) received from the AS
to the RS. The RS then generates a nonce N2 and an identifier ID2
unique in the sets of its own Recipient IDs, and uses Section 3.2 of
[RFC8613] to derive a security context based on a shared master
secret, the two nonces and the two identifiers, established between
client and server. The nonces and identifiers are encoded as CBOR
byte string if CBOR is used, and as Base64 string if JSON is used.
This security context is used to protect all future communication
between client and RS using OSCORE, as long as the access token is
valid.
<mglt>
all communication sounds strange to me. I am
wondering if that is not all communicationS
instead - though not being native English.
Similarly I think that the communication is
between a specific client and a specific RS -
at least once established. Thus I am
wondering if that should not be 'between THE
client and THE RS instead.
</mglt>
Note that the RS and client authenticates each other by generating
the shared OSCORE Security Context using the pop-key as master
secret. An attacker posting a valid token to the RS will not be able
to generate a valid OSCORE Security Context and thus not be able to
prove possession of the pop-key. Additionally, the mutual
authentication is only achieved after the client has successfully
verified a response from the RS protectd with the generated OSCORE
Security Context.
<mglt>
I think that is RS protected.
It is unclear - at this stage of reading if
the exchange that performs the mutual
authentication is a specific exchange or the
communication between the client and the RS.
</mglt>
Palombini, et al. Expires June 17, 2021 [Page 15]
Internet-Draft OSCORE Profile of ACE December 2020
4.1. C-to-RS: POST to authz-info endpoint
The client MUST generate a nonce value very unlikely to have been
previously used with the same input keying material. This profile
RECOMMENDS to use a 64-bit long random number as nonce's value. The
client MUST store the nonce N1 as long as the response from the RS is
not received and the access token related to it is still valid (to
the best of the client's knowledge).
<mglt>
Same comment as in the overview section
regarding the nonce randomly generated. It
seems that random generation does not require
storing any context resilient to reboot.
</mglt>
The client generates its own Recipient ID, ID1, for the OSCORE
Security Context that it is establishing with the RS. By generating
its own Recipient ID, the client makes sure that it does not collide
with any of its Recipient IDs, nor with any other identifier ID1 if
the client is executing this exchange with a different RS at the same
time.
<mglt>
This paragraph is really clarifying - and to
me necessary.
</mglt>
The client MUST use CoAP and the Authorization Information resource
as described in section 5.8.1 of [I-D.ietf-ace-oauth-authz] to
transport the token, N1 and ID1 to the RS.
Note that the use of the payload and the Content-Format is different
from what is described in section 5.8.1 of
[I-D.ietf-ace-oauth-authz], which only transports the token without
any CBOR wrapping. In this profile, the client MUST wrap the token,
N1 and ID1 in a CBOR map. The client MUST use the Content-Format
"application/ace+cbor" defined in section 8.14 of
[I-D.ietf-ace-oauth-authz]. The client MUST include the access token
using the 'access_token' parameter, N1 using the 'nonce1' parameter
defined in Section 4.1.1, and ID1 using the 'ace_client_recipientid'
parameter defined in Section 4.1.2.
<mglt>
The paragraph above is also really
clarifying.
</mglt>
[...]
4.2. RS-to-C: 2.01 (Created)
[...]
<mglt>
It seems to me that the text is using
OSCORE_Input_Material, so I would say we
should remain coherent through the document.
I personnaly do not believe '_' are needed
and would probably favor the designation used
here.
</mglt>
the context used to protect the message. If that is the case, the RS
MUST overwrite the old token and associate the new token to the
Security Context identified by the "kid" value in the 'cnf' claim.
The RS MUST respond with a 2.01 (Created) response protected with the
same Security Context, with no payload. If any verification fails,
the RS MUST respond with a 4.01 (Unauthorized) error response.
As specified in section 5.8.1 of [I-D.ietf-ace-oauth-authz], when
receiving an updated access token with updated authorization
information from the client (see Section 3.1), it is recommended that
the RS overwrites the previous token, that is only the latest
authorization information in the token received by the RS is valid.
This simplifies the process needed by the RS to keep track of
authorization information for a given client.
[...]
4.3. OSCORE Setup
Once receiving the 2.01 (Created) response from the RS, following the
POST request to authz-info endpoint, the client MUST extract the bstr
nonce N2 from the 'nonce2' parameter in the CBOR map in the payload
of the response. Then, the client MUST set the Master Salt of the
Security Context created to communicate with the RS to the
concatenation of salt, N1, and N2, in this order: Master Salt =
salt | N1 | N2, where | denotes byte string concatenation, where salt
is the CBOR byte string received from the AS in Section 3.2, and
where N1 and N2 are the two nonces encoded as CBOR byte strings. An
example of Master Salt construction using CBOR encoding is given in
Figure 12.
N1, N2 and input salt expressed in CBOR diagnostic notation:
nonce1 = h'018a278f7faab55a'
nonce2 = h'25a8991cd700ac01'
input salt = h'f9af838368e353e78888e1426bd94e6f'
N1, N2 and input salt as CBOR encoded byte strings:
nonce1 = 0x48018a278f7faab55a
nonce2 = 0x4825a8991cd700ac01
input salt = 0x50f9af838368e353e78888e1426bd94e6f
Master Salt = 0x50 f9af838368e353e78888e1426bd94e6f 48 018a278f7faab55a 48
25a8991cd700ac01
Figure 12: Example of Master Salt construction using CBOR encoding
If JSON is used instead of CBOR, the Master Salt of the Security
Context is the Base64 encoding of the concatenation of the same
parameters, each of them prefixed by their size, encoded in 1 byte.
When using JSON, the nonces and input salt have a maximum size of 255
bytes. An example of Master Salt construction using Base64 encoding
is given in Figure 13.
Palombini, et al. Expires June 17, 2021 [Page 20]
Internet-Draft OSCORE Profile of ACE December 2020
N1, N2 and input salt values:
nonce1 = 0x018a278f7faab55a (8 bytes)
nonce2 = 0x25a8991cd700ac01 (8 bytes)
input salt = 0xf9af838368e353e78888e1426bd94e6f (16 bytes)
Input to Base64 encoding: 0x10 f9af838368e353e78888e1426bd94e6f 08
018a278f7faab55a 08 25a8991cd700ac01
Master Salt = b64'EPmvg4No41PniIjhQmvZTm8IAYonj3+qtVoIJaiZHNcArAE='
Figure 13: Example of Master Salt construction using Base64 encoding
The client MUST set the Sender ID to the ace_server_recipientid
received in Section 4.2, and the Recipient ID to the
ace_client_recipientid sent in Section 4.1.
<mglt>
It seems to me that the terminology used here
might be a bit misleading. If
ace_server_recipientid is being used as the
SID, it seems that ace_server_receipientid
and ace_client_recipientid could be
designated as ace_server_id and
ace_client_id. What matters then is that the
IDs in a message can be interpreted by the
receiving side and that the receiving side
can see its ID. In OSCORE that ID is called
the Sender ID (SID) which in this example
should be set to ace_server_id. It seems to
me that these Sender and Recipient are only
here to indicate a direction and that Sender
ID is a bit misleading - but that is what we
have with OSCORE. I am wondering if my
understanding is correct or if I am missing
something.
</mglt>
The client MUST set the
Master Secret from the parameter received from the AS in Section 3.2.
The client MUST set the AEAD Algorithm, ID Context, HKDF, and OSCORE
Version from the parameters received from the AS in Section 3.2, if
present. In case an optional parameter is omitted, the default value
SHALL be used as described in sections 3.2 and 5.4 of [RFC8613].
After that, the client MUST derive the complete Security Context
following section 3.2.1 of [RFC8613]. From this point on, the client
MUST use this Security Context to communicate with the RS when
accessing the resources as specified by the authorization
information.
If any of the expected parameters is missing (e.g., any of the
mandatory parameters from the AS or the RS), or if
ace_client_recipientid equals ace_server_recipientid, then the client
MUST stop the exchange, and MUST NOT derive the Security Context.
The client MAY restart the exchange, to get the correct security
material.
<mglt>
ace_client_id and ace_server_id may collide.
It is unclear to me what problem it causes.
Contexts are being indexed with the ID being
used as a recipient and the binding between
an RID and a context seems only be necessary
for a receiving party. When a node is sending
some data, it might needs the Sending Context
but it is not crucial to index it with an ID,
nor to have all Sending and Receiving Context
mixed together. As a result, I have the
impression that this case of equality is an
implementation issue. Of course I might be
missing something.
I suggest motivation is provided, and unless
we have some the corner case is removed and
let to implementations.
</mglt>
The client then uses this Security Context to send requests to the RS
using OSCORE.
After sending the 2.01 (Created) response, the RS MUST set the Master
Salt of the Security Context created to communicate with the client
to the concatenation of salt, N1, and N2, in the same way described
above. An example of Master Salt construction using CBOR encoding is
given in Figure 12 and using Base64 encoding is given in Figure 13.
The RS MUST set the Sender ID from the ace_client_recipientid
received in Section 4.1, and the Recipient ID from the
ace_server_recipientid sent in Section 4.2. The RS MUST set the
Master Secret from the parameter received from the AS and forwarded
by the client in the access token in Section 4.1 after validation of
the token as specified in Section 4.2. The RS MUST set the AEAD
Algorithm, ID Context, HKDF, and OSCORE Version from the parameters
Palombini, et al. Expires June 17, 2021 [Page 21]
Internet-Draft OSCORE Profile of ACE December 2020
received from the AS and forwarded by the client in the access token
in Section 4.1 after validation of the token as specified in
Section 4.2, if present. In case an optional parameter is omitted,
the default value SHALL be used as described in sections 3.2 and 5.4
of [RFC8613]. After that, the RS MUST derive the complete Security
Context following section 3.2.1 of [RFC8613], and MUST associate this
Security Context with the authorization information from the access
token.
The RS then uses this Security Context to verify requests and send
responses to the client using OSCORE. If OSCORE verification fails,
error responses are used, as specified in section 8 of [RFC8613].
Additionally, if OSCORE verification succeeds, the verification of
access rights is performed as described in section Section 4.4. The
RS MUST NOT use the Security Context after the related token has
expired, and MUST respond with a unprotected 4.01 (Unauthorized)
error message to requests received that correspond to a Security
Context with an expired token.
Note that the ID Context can be assigned by the AS, communicated and
set in both the RS and client after the exchange specified in this
profile is executed. Subsequently, client and RS can update their ID
Context by running a mechanism such as the one defined in
Appendix B.2 of [RFC8613] if they both support it and are configured
to do so.
<mglt>
I am reading the text as if that works they
will be able to update the ID, but there is
no guarantee for that. I would expect some
ways to announce the support of such
mechanism.
</mglt>
In that case, the ID Context in the OSCORE Security
Context will not match the "contextId" parameter of the corresponding
OSCORE_Input_Material.
<mglt>
Well, I might be missing something, but I
have the impression the mechanism has been
designed to mitigate the contextID and the id
when they are equal. I suppose having these
id matching raises some issues, but it is
unclear to me what the issue is. I am also
wondering - as mentioned earlier whether we
need to have these two ID, and if so, if that
could be possible to derive these IDs one
from another. This would prevent the defining
a mechanism.
Currently here is how I see the situation:
a) the collision might be an issue, and
b) we might have a mechanism to address this
potential issue.
Note that I might emphasize the issue too
much, that is just to clarify my thoughts.
</mglt>
Running Appendix B.2 results in the keying
material in the Security Contexts of client and RS being updated;
this same result can also be achieved by the client reposting the
access token to the unprotected /authz-info endpoint at the RS, as
described in Section 4.1, but without updating the ID Context.
[...]
6. Discarding the Security Context
On Mon, Dec 14, 2020 at 10:46 AM Francesca Palombini <francesca.palombini=
[email protected]> wrote:
> Ah, of course, they are indeed out of sync, thank you for noticing! I am
> fixing it already in the github, but I am thinking of waiting for Daniel's
> go ahead before submitting one more version, see if he wanted to review one
> last time.
>
> Francesca
>
> On 14/12/2020, 16:32, "Benjamin Kaduk" <[email protected]> wrote:
>
> Thanks, Francesca!
>
> It looks like the CBOR label values have gotten out of sync between
> Table 1
> and the prose. (The IANA Considerations just refer to Table 1, so I
> think
> that Section 3.2.1 is the only thing that needs to be kept in sync.)
>
> -Ben
>
> On Mon, Dec 14, 2020 at 09:58:21AM +0000, Francesca Palombini wrote:
> > Hi all,
> >
> > This update answers Marco's latest review (thanks Marco!), answering
> all comments received as WGLC.
> >
> > Thanks,
> > Francesca
> >
> > On 14/12/2020, 09:49, "Ace on behalf of [email protected]" <
> [email protected] on behalf of [email protected]> wrote:
> >
> >
> > A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
> > This draft is a work item of the Authentication and
> Authorization for Constrained Environments WG of the IETF.
> >
> > Title : OSCORE Profile of the Authentication
> and Authorization for Constrained Environments Framework
> > Authors : Francesca Palombini
> > Ludwig Seitz
> > Göran Selander
> > Martin Gunnarsson
> > Filename : draft-ietf-ace-oscore-profile-14.txt
> > Pages : 33
> > Date : 2020-12-14
> >
> > Abstract:
> > This memo specifies a profile for the Authentication and
> > Authorization for Constrained Environments (ACE) framework.
> It
> > utilizes Object Security for Constrained RESTful Environments
> > (OSCORE) to provide communication security and
> proof-of-possession
> > for a key owned by the client and bound to an OAuth 2.0
> access token.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-ace-oscore-profile-14
> >
> https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-14
> >
> > A diff from the previous version is available at:
> >
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oscore-profile-14
> >
> >
> > Please note that it may take a couple of minutes from the time
> of submission
> > until the htmlized version and diff are available at
> tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> >
> > _______________________________________________
> > Ace mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/ace
> >
> > _______________________________________________
> > Ace mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/ace
>
> _______________________________________________
> Ace mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ace
>
--
Daniel Migault
Ericsson
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
