From nobody Wed Jan 1 14:33:12 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E019612000F; Wed, 1 Jan 2020 14:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4w13iHL70zCV; Wed, 1 Jan 2020 14:33:08 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EAEE1200E5; Wed, 1 Jan 2020 14:33:08 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 1 Jan 2020 14:33:02 -0800 From: Jim Schaad To: CC: Date: Wed, 1 Jan 2020 14:33:01 -0800 Message-ID: <007401d5c0f3$6e80d320$4b827960$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdW97v+NY+D9VnkFSKqytakbDag3Kg== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-03 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jan 2020 22:33:10 -0000 2.2.2 - para 1, the last sentence seems to imply that the first connection to publish to authz-info is not being done over a TLS connection. But the sentence before that states that a TLS connection MUST be used for this. Perhaps s/and is expected to try reconnecting over TLS./and reconnects, potentially using client authentication with TLS./ 2.2.2 - I am unclear under what circumstances you could end put with a token which does not parse when processing a PUBLISH message. If the token cannot be parsed at connection time, that I can understand. However having parsed the token then it does not make sense that the token becomes not parsable at the time of publishing. Am I missing something? 2.2.2 - The last paragraph is causing me confusion. Is this supposed to be referencing the RS or the AS? If it is the AS, then I don't see how there could be any confusion. Please expand this so it is clearer. 2.2.4 - I am having a problem with trying to parse the content of the AUTH property. I have no problems with 2.2.4.3 because this is a zero length sequence of bytes. However for 2.2.4.1 and 2.2.4.2 there is a token (possibly binary with no length prefix) followed by an optional binary cryptographic value. For introspection, I would need to figure out the length of the token before I could make a guess at the length of the cryptographic value. However given that there is no divider this does not seem possible. This may also become a problem for the response from the client in the event that there is a change from an 8-byte nonce to a variable length one. 2.2.4.1 - In my view it is not the secret, but the content that is being obtained from the TLS exporter. That is one is signing (or MACing) the exporter value not using that value to compute a MAC on something else. While it is true that only the two parties know that value, exposure to a third party does not lead to a compromise. 2.2.4.3 - I am not sure if the text is supposed to require an empty authentication data field or to allow for the authentication data field to be absent as well. 3 - It might be worth while to put a pointer to section 4.7 of the MQTT V5 spec here so that there is an indication of what the different wild card characters do. I had to pop over there to make sure that I could figure it out. 3.1 - Should you state that for a QoS of 0, the client should close the connection w/ an '0x87' in the event of an authorization failure? I think that this is supposed to happen but you have left it open. 6 - It is not clear to me if the authentication method described in this section is permitted with MQTT v5 or not. It does not say, but it appears to be a true statement. This should probably be explicit. 2.2.4.3 - What is the name of the user property that is being returned here? I am going to play with something else. I am sure I will find other issues at a different time. Jim Nits: Section 2 Para 1 s/Broker.Figure 1/Broker. Figure 1/ Section 2 Para 1 s/setup.The/setup. The/ Section 2.2.2 Last Para s/when the AS/when the RS/ From nobody Thu Jan 2 15:40:34 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19B6120170; Thu, 2 Jan 2020 15:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgpFVd5Ok_Nr; Thu, 2 Jan 2020 15:40:28 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36DAB120105; Thu, 2 Jan 2020 15:40:25 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 002NeKMv022833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 2 Jan 2020 18:40:23 -0500 Date: Thu, 2 Jan 2020 15:40:20 -0800 From: Benjamin Kaduk To: draft-ietf-ace-dtls-authorize.all@ietf.org Cc: ace@ietf.org Message-ID: <20200102234020.GI35479@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2020 23:40:33 -0000 Hi all, Some high-level remarks before delving into the section-by-section comments: This document is pretty clearly DTLS 1.2-specific -- it talks about particular protocol messages, message fields, and cipher suites that simply do not apply to DTLS 1.3. In order to use this profile with DTLS 1.3, we'd need to specify the analogous behavior/requirements to these (including standalone signature schemes and key-exchange groups, which are now both separately negotiated from the cipher suite). Given that DTLS 1.3 is past WGLC and only a few documents behind this one in my review queue, it seems fairly prudent to spend some time and cover how DTLS 1.3 would work here, since otherwise this document will become stale shortly after (or even before!) its publication as an RFC. There's probably some additional discussion to include about the usage of key identifiers in this document versus the potential uses described in the core framework. Specifically, the framework reminds us that "no assumptions should be made that it is unique in the domains of either the client or the RS" yet this document is using the kid as input to a KDF that produces keys that must be unique across all clients, and allowing live/instant authorization updates based on matching "kid". How shall we resolve this apparent conflict? We also are potentially in violation of the framework's requirements with respect to the independent selection of profiles for client/AS and client/RS interactions -- at present, when DTLS+RPK is used for client/RS, we require that DTLS+RPK is also used for client/AS, in order to prove possession of the key. We could perhaps weasel our way out by saying that the framework's requirement applies at the profile granularity, and with symmetric PSK we can be fully independent, but we still need to say something about this property and the interaction with the framework's requirements. This profile is mostly applicable to the client/RS communications and feels like it only provides some of the picture for use with client/AS interactions. (It doesn't really say much of anything about RS/AS interactions.) The introductory discussion does not do a great job of painting that picture, and I'd like to see it more clearly introduced that the bulk of our coverage is for the client/RS interaction. We also lean heavily on the existing out-of-band configuration and key material shared between client and AS to secure the client/AS communications; we could probably tighten up the discussion about exactly what parameters of client/AS communication are specified by this profile. We do not say anything about DTLS session resumption (or renegotiation, though not talking about that one is perfectly fine); that's a fairly core DTLS concept that we should give some guidance on. Looking through Appendix C ("Requirements on Profiles") of the framework, do we want to say anything about: - using the client credentials grant with this profile, as that's IIRC the only example we show - require that DTLS be used in a mode that provides replay protection - when the client uses the authz-info endpoint instead of the "psk_identity" field to convey the token to the RS, how does the RS know which client is connecting (and thus what PSK to use), and what does the client actually *put* in the "psk_identity" field? (The other aspects of "how to select a proof-of-possession protocol" seem to fall out naturally from the DTLS usage.) - whether/how introspection is used? - give more details of what this profile mandates when used for client/AS interactions (as mentioned above) - explicitly state that the authz-info endpoint is unprotected (or that it might be protected if, e.g., the RS has a trustable certificate that would be used instead of RPK or PSK, or by supplying the token as the "psk_identity" when symmetric PoP is used, or by only doing server-authentication with RPK as known by the client by the rs_cnf access information And now, on to the section-by-section comments. Section 1 a DTLS session. The communication between client and authorization server may also be secured with DTLS. This specification supports DTLS with Raw Public Keys (RPK) [RFC7250] and with Pre-Shared Keys (PSK) [RFC4279]. [DTLS 1.3 will inherit TLS 1.3's built-in support for (so-called "external") PSKs.] The DTLS handshake requires the client and server to prove that they can use certain keying material. In the RPK mode, the client proves with the DTLS handshake that it can use the RPK bound to the token and the server shows that it can use a certain RPK. The access token must be presented to the resource server. For the RPK mode, the access token needs to be uploaded to the resource server before the handshake is initiated, as described in Section 5.8.1 of the ACE framework [I-D.ietf-ace-oauth-authz]. This seems to be making some implicit assumptions about the message flow that have not yet been covered by this document and are only somewhat covered by the core framework spec. I'd propose: % The ACE framework requires that client and server mutually % authenticate each other before any other protocol exchanges take % place. In order for DTLS to provide mutual authentication, both % client and server must prove their ability to use certain keying % material (tied to the authenticated identity) as part of the DTLS % handshake. The AS assists in this process by incorporating key % material (or information about key material) into the access token, % which is considered a "proof of possession" token. In the RPK mode, % the client proves that it can use the RPK bound to the token and the % server shows that it can use a certain RPK (as indicated by the AS to % the client). The resource server needs access to the token in order % to complete this exchange. For the RPK mode, the access token needs % to be uploaded to the resource server before the handshake is % initiated, as described in Section 5.8.1 of the ACE framework % [I-D.ietf-ace-oauth-authz]. though I recognize that my text tends to be a bit more verbose than is strictly needed, so please feel free to edit it down. Section 2 The CoAP-DTLS profile for ACE specifies the transfer of authentication information and, if necessary, authorization information between the client (C) and the resource server (RS) during setup of a DTLS session for CoAP messaging. It also specifies how C can use CoAP over DTLS to retrieve an access token from the authorization server (AS) for a protected resource hosted on the resource server. I suggest reiterating that "As specified in Section 6.7 of [I-D.ietf-ace-oauth-authz], use of DTLS for one or both of these interactions is completely independent". To determine the AS in charge of a resource hosted at the RS, C MAY send an initial Unauthorized Resource Request message to the RS. The This is part of the core framework, so the "MAY" may be overkill. (Lowercase "can" would do just fine.) Once the client knows the authorization server's address, it can send an access token request to the token endpoint at the AS as specified Hmm. There's some level of "the client needs to have already been configured that that AS is a valid AS" verification that's done here, but I'm not sure if that's too much detail to include at this stage (since we're really just summarizing the framework here). in [I-D.ietf-ace-oauth-authz]. As the access token request as well as the response may contain confidential data, the communication between the client and the authorization server MUST be (This "MUST" is already a requirement from the core framework, so we don't necessarily need to repeat it as normative language.) confidentiality-protected and ensure authenticity. C may have been registered at the AS via the OAuth 2.0 client registration mechanism as outlined in Section 5.3 of [I-D.ietf-ace-oauth-authz]. Section 5.3 of oauth-authz says that registration is "out of scope"; is this still the right reference? [I-D.ietf-ace-oauth-authz]. In case the client uses a symmetric proof-of-possession key in the DTLS handshake, the procedure as above MAY be used, or alternatively, the access token MAY instead be transferred in the DTLS ClientKeyExchange message (see Section 3.3.1). (This is not DTLS 1.3-compatible.) Section 3 secured. Depending on the used CoAP security mode (see also Section 9 of [RFC7252], the Client-to-AS request, AS-to-Client response and DTLS session establishment carry slightly different information. [...] At this point in the document it's pretty unclear what "Client-to-AS request", "AS-to-Client response", and "DTLS session establishment" are and how they relate to each other. Also, it seems like the behavior in Section 3.2 and 3.3 are relating to the mode used for the client/RS interactions, which relates to the client/AS interactions only in the form of how PoP information is bound to/with the token. Section 3.1 establish a secure communication channel. C MUST securely have obtained keying material to communicate with AS. Furthermore, C MUST verify that AS is authorized to provide access tokens (including authorization information) about RS to C. Also, AS MUST securely have obtained keying material for C, and obtained authorization rules approved by the resource owner (RO) concerning C and RS that relate to this keying material. [...] The way this is written right now, we're going to get lots of questions from reviewers about "how does this happen?" and for more details about it. We are effectively assuming that this stuff is all provisioned already as part of the device configuration or during enrollment, we should say something about these being requirements on device provisioning, not on the operation of the ACE protocol. between C and AS is bootstrapped is not part of this document. C and AS MUST ensure the confidentiality, integrity and authenticity of all exchanged messages. I think this is also restating requirements from the core framework, and may not need normative language in this manner. Section 3.2 I know that the section heading says "RawPublicKey Mode" already, but I'd recommend adding a sentence in the preface that repeats that "When the client and RS use RawPublicKey authentication, the procedure is as follows"; we might get complaints otherwise that we are saying that the client MUST do things that are not universal requirements. (Section 3.3 does already have something like this for the symmetric-key case.) previously made known to the authorization server. To prove that the client is in possession of this key, C MUST use the same keying material that it uses to secure the communication with AS, e.g., the DTLS session. This seems in conflict with the core framework's requirement that the client/AS profile and client/RS profile are severable. AS MUST check if the client that it communicates with is associated with the RPK in the cnf object before issuing an access token to it. Earlier in the section we noted a requirement to prove possession of the key by using it in DTLS; why is there a separate "association" requirement? also, nit: "The AS". which case it does not have to be sent. The response also contains an access token and an "rs_cnf" parameter containing information about the public key that is used by the resource server. AS MUST nit(?): is the "rs_cnf" parameter always mandatory? (Or only when DTLS-RPK is used for client-RS interactions?) nit: "The AS" again (and throughought, to a large extent). server that C wants to communicate with. AS MUST protect the integrity of the token. If the access token contains confidential data, AS MUST also protect the confidentiality of the access token. This requirement ("protect the integrity of the token") feels a little underspecified, as it doesn't say protection over what workflow or who will verify the integrity (the RS). C MUST ascertain that the access token response belongs to a certain previously sent access token request, as the request may specify the resource server with which C wants to communicate. nit: I recomment rewording "belongs to", perhaps as "corresponds to". DTLS can provide this guarantee when configured to do so, though it is not a guaranteed property from DTLS. We'll probably get some grief about the "access_token" contents in the example not being valid CBOR, due to the parenthetical comment. We could probably put a note in the preface that the value is truncated for readability. Also, nit: "the client's" with article and apostrophe. Section 3.2.1 Before the client initiates the DTLS handshake with the resource server, C MUST send a "POST" request containing the new access token to the authz-info resource hosted by the resource server. After the client nit: we don't require single-use tokens, so "new" is probably overkill; just "its access token" should suffice. nit: formatting issue with spurious line break here. server. To use the RawPublicKey mode, the client MUST specify the public key that AS defined in the "cnf" field of the access token response in the SubjectPublicKeyInfo structure in the DTLS handshake as specified in [RFC7250]. IIRC the access token response does not have to include a "cnf" field (e.g., if the AS accepts the req_cnf from the request), so "defined in the field of the response" doesn't seem like quite the right wording. An implementation that supports the RPK mode of this profile MUST at least support the ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 I understand that making the full-width-tag ciphersuite MTI would exclude some devices, though it feels like some recommendation to use the full-length tag when possible would be appropriate. That said, I do see that RFC 7252 makes no such remark, and thus consistency would have us not say anything either. [RFC7251] with the ed25519 curve (cf. [RFC8032], [RFC8422]). Just to be clear: ed25519 is an ECDSA algorithm; the corresponding ECDHE operation is called x25519, and both algorithms make use of the elliptical curve known as curve25519. Since we are using both ECDHE and ECDSA, it's probably simplest to just refer to "curve25519", though mentioning both ed25519 and x25519 would also work. RS MUST check if the access token is still valid, if RS is the intended destination, i.e., the audience, of the token, and if the token was issued by an authorized AS. The access token is nit: "i.e., the audience" is in effect a parenthetical, so using commas to offset it inside a comma-separated list is potentially confusing; I'd suggest using actual parentheses instead of commas around it. reference to this key. If the authorization server has no certain knowledge that the Client's key is already known to the resource server, the Client's public key MUST be included in the access token's "cnf" parameter. If CBOR web tokens [RFC8392] are used as recommended in [I-D.ietf-ace-oauth-authz], keys MUST be encoded as specified in [I-D.ietf-ace-cwt-proof-of-possession]. RS MUST use the Is talking about """the access token's "cnf" parameter" consistent with allowing the use of non-CWT (non-JWT) token formats? keying material in the handshake that AS specified in the rs_cnf parameter in the access token. Thus, the handshake only finishes if C and RS are able to use their respective keying material. I suggest being explicit about "the DTLS handshake with the client", perhaps as "MUST use in the DLTS handshake with the client the keying material that the AS specified in the rs_cnf parameter in the access token". The same caveat about "parameter in the access token" applies here, though I guess there is an additional complication for "rs_cnf" in that it's an token response parameter but I don't remember that we say a huge amount about it also being included in the token itself -- the token response is directed to the client but the token is directed to the RS. Section 3.3 token. AS MUST check if the identifier refers to a symmetric key that was previously generated by AS as a shared secret for the communication between this client and the resource server. "What does the AS do if this check fails?" The authorization server MUST determine the authorization rules for the C it communicates with as defined by RO and generate the access nit: it's surprising to see "authorization server" spelled out in the same sentence as "C" and "RO" (which, incidentally, we don't seem to use in abbreviation form anywhere other than where we define it). wants to communicate with. Also, AS MUST protect the integrity of the access token. If the token contains confidential data such as the symmetric key, the confidentiality of the token MUST also be protected. Depending on the requested token type and algorithm in (same comment about "protect the integrity" or "protect" as for the RPK case.) that is to be used between C and the resource server. The access token MUST be bound to the same symmetric key by means of the cnf claim. Now we call it a "claim" rather than a "token parameter", but this again seems to be implicitly assuming CWT/JWT for tokens. (Also, this "MUST" seems like something that the framework should guarantee and not a new requirement that the DTLS profile imposes.) Figure 5: Example Access Token Request, symmetric PoP-key Maybe we could include "(implicit)" in the caption, since symmetric PoP key is the default. An example access token response is illustrated in Figure 6. In this Is it accurate to say "A corresponding example access token response"? It's nice to the reader if we can tie the examples together like that. Is the "Max-Age" usage in Figure 6 typical? (Also, similar comment about having the parenthetical comment in the example body vs. preface.) token_type : pop, Didn't we switch this to being capitalized as "PoP"? "COSE_Encrypt0" structure. The AS MUST use the keying material shared with the RS to encrypt the token. nit: I suggest s/shared with/it shares with/ We should probably say something about why the kid in Figure 7 is different from the one in Figure 6. 4.00 Bad Request Content-Format: application/ace+cbor Payload: { error : invalid_request } Figure 8: Example Access Token Response With Reject RFC 6749's description of "invalid_request" seems to imply that it's mostly about malformed requests, as opposed to the AS deciding that the client is not authorized for any access to the requested resource (which is maybe what's implied by the previous paragraph). This is not necessarily a problem, but perhaps we could make the text and example more consistent. The method for how the resource server determines the symmetric key from an access token containing only a key identifier is application specific, the remainder of this section provides one example. nit: hyphenate "application-specific", and this is a comma splice. resource server. This key needs to be securely stored and processed in the same way as the key used to protect the communication between AS and RS. nit: is this better as "processed" or "protected"? The fields in the context information "COSE_KDF_Context" (Section 11.2 of [RFC8152]) have the following values: o AlgorithmID = "ACE-CoAP-DTLS-key-derivation" RFC 8152 says that these AlgorithmID values come from the COSE Algorithms registry, which this does not (unless we register it there, which we don't currently). Also, since the output is used directly for DTLS PSK, I don't think the "key-derivation" portion is needed. o PartyUInfo = PartyVInfo = ( null, null, null ) (8152 seems to prefer "nil" over "null".) o keyDataLength needs to be defined by the application o protected MUST be a zero length bstr o other is a zero length bstr (These three are all members of the "SuppPubInfo" field, which is not very clear from how we include them in the same list as top-level fields.) Section 3.3.1 When a client receives an access token response from an authorization server, C MUST ascertain that the access token response belongs to a certain previously sent access token request, as the request may specify the resource server with which C wants to communicate. (Same bit about "belongs to".) If a resource server receives a ClientKeyExchange message that contains a "psk_identity" with a length greater zero, it uses the contents as index for its key store (i.e., treat the contents as key (This is not DTLS 1.3-compatible.) nits: "greater than", "as an index", "as a key identifier" identifier). The resource server MUST check if it has one or more access tokens that are associated with the specified key. I don't understand this sentence -- isn't the access token the precise contents of the "psk_identity" field, so that there would be a key associated with the access token, not the other way around? If no key with a matching identifier is found, the resource server MAY process the contents of the "psk_identity" field as access token Similarly here, the causality feels reversed. continuing the DTLS handshake. If the contents of the "psk_identity" do not yield a valid access token for the requesting client, the DTLS session setup is terminated with an "illegal_parameter" DTLS alert message. I think "the RS aborts the DTLS handshake with an 'illegal_parameter' alert" would be more conventional phrasing. Note2: According to [RFC7252], CoAP implementations MUST support the ciphersuite TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]. A client is therefore expected to offer at least this ciphersuite to the resource server. Do we want to say anything about the (EC)DHE variants? Short-lived access tokens with the AS generating new symmetric keys can provide similar forward-secrecy properties to using DHE, but there is in general a trend in the IETF towards defaulting to providing forward secrecy in key exchanges. When RS receives an access token, RS MUST check if the access token is still valid, if RS is the intended destination, i.e., the audience of the token, and if the token was issued by an authorized AS. This As above, "i.e., the audience of the token" would probably be better when offset in parentheses than by commas. While the client can retrieve the shared secret from the contents of the "cnf" parameter in the AS-to-Client response, the resource server uses the information contained in the "cnf" claim of the access token to determine the actual secret when no explicit "kid" was provided in the "psk_identity" field. If key derivation is used, the RS uses the "COSE_KDF_Context" information as described above. "psk_identity" is a field in ClientKeyExchange, and we say that its contents are the raw access token for our usage. It does not have a direct COSE structure for this talk of "kid" to make much sense without further explanation. Section 3.4 We may get some requests for a more explicit definition of what the "authorization information" tied to a client is. Once a DTLS channel has been established as described in Section 3.2 and Section 3.3, respectively, the client is authorized to access nit: I think "or" is more appropriate to join the sections listed, as only one is applicable to a given connection. With the successful establishment of the DTLS channel, C and RS have proven that they can use their respective keying material. An access token that is bound to the client's keying material is associated with the channel. Any request that the resource server receives on this channel MUST be checked against these authorization rules. RS nit: I'd s/these/the following/ MUST check for every request if the access token is still valid. Incoming CoAP requests that are not authorized with respect to any access token that is associated with the client MUST be rejected by the resource server with 4.01 response as described in Section 5.1.1 of [I-D.ietf-ace-oauth-authz]. "any access token" implies there might be more than one, though I seem to recall discussion of updated tokens overwriting any previous one, so that only one token per client is active at any given time. What did we end up settling on? Also, the referenced framework Section 5.1.1 does not actually mandate the 4.01 response code. The resource server SHOULD treat an incoming CoAP request as authorized if the following holds: We could say more about this "SHOULD" (or change the way we discuss it) -- is it the minimum baseline of checks and additional checks may be applied, or do some of them not apply in some cases, or ...? Incoming CoAP requests received on a secure DTLS channel that are not thus authorized MUST be rejected according to Section 5.8.2 of [I-D.ietf-ace-oauth-authz] We may also get some questions asking about what the difference is between the "not authorized with respect to any access token" in the previous quoted snippet" and "not thus authorized" in this quoted snippet. The client cannot always know a priori if an Authorized Resource Request will succeed. It MUST check the validity of its keying material before sending a request or processing a response. If the What does "check the validity of its keying material" mean? client repeatedly gets error responses containing AS Creation Hints (cf. Section 5.1.2 of [I-D.ietf-ace-oauth-authz] as response to its requests, it SHOULD request a new access token from the authorization server in order to continue communication with the resource server. Why should this only be done in the case of *repeatedly* getting such error responses; I thought the idea of the AS Request Creation Hints was to take immediate effect. (Also, nit: s/AS Creation Hints/AS Request Creation Hints/.) Section 4 The client can update the authorization information stored at the resource server at any time without changing an established DTLS session. To do so, the Client requests a new access token from the authorization server for the intended action on the respective resource and uploads this access token to the authz-info resource on the resource server. I suggest adding another sentence similar to "Because ACE tokens are proof-of-possession tokens, the updated authorization information only takes immediate effect if such proof has already been provided, e.g., if the PoP key associated with the new token is the same as the one currently in use." This is further detailed in the following paragraphs, but not stated concretely as a key principle. Section 5 DTLS sessions that have been established in accordance with this profile are always tied to a specific access token. As this token Doesn't the dynamic authorization update mechanism allow that token to be swapped out during the lifetime of the connection? Also, as a terminology point, I think "DTLS association" is more appropriate than "DTLS session" for what we describe, since the token is is tied to the client and consulted at the start of the handshake, as opposed to being a property of the DTLS session and carried across resumptions. may become invalid at any time (e.g. because it has expired), the session may become useless at some point. A resource server therefore MUST terminate existing DTLS sessions after the access token for this session has been deleted. I assume that using "been deleted" vs. "has expired" is a deliberate choice? If we don't say anything else about when to delete tokens, it doesn't post much of a requirement, though. Section 6 endpoint. The use of CoAP and DTLS for this communication is RECOMMENDED in this profile, other protocols (such as HTTP and TLS or CoAP and OSCORE) MAY be used instead. nit: comma splice Also, we could potentially refer to the OSCORE profile document here (informatively). If other means of securing the communication with the AS are used, the security protocol MUST fulfill the communication security requirements in Section 6.2 of [I-D.ietf-ace-oauth-authz]. I suggest phrasing more like "the communication security requirements from Section 6.2 of [I-D.ietf-ace-oauth-authz] remain applicable", since there's no need to add another MUST to the ones already in the framework document. Section 7 I have a few suggestions for potential additions to this section as well as comments on the existing contents. We might consider adding a brief note about the use of 8-byte authentication tags in DTLS ciphers and how that affects the risk profile. The use of "live" authorization upgrades on an existing DTLS connection by posting a new token to the authz-info endpoint does not provide much guarantee about the order in which operations occur (and thus which authorization info is used to process a given client request), especially in the face of an attacker that can delay and reorder packets. This does not necessarily mean that we should not bother to define that mechanism, but we should point out that there is only a weak ordering property provided, note that other mechanisms should be used when strict serialization is important, and caution that when the later-issued token contains a reduction in authorization from the initial token, it is impossible to guarantee that the reduction in authorization will take effect prior to the expiration of the original token. We rely heavily on the AS to accurately provide binding of raw key material to authorization information and endpoint identinty; I think this is a stronger reliance than just that implied by the core architecture, and so might merit a mention here. (This relates to all the checks about "MUST check that [client/...] is associated with [RPK/PSK]" that appear throughout the document.) I'd also suggest reiterating all the places where we rely on out-of-band configuration, as there's always a risk of such configuration becoming stale (or getting attacked directly). I'd consider reiterating that when the KDF scheme is in use between RS and AS, that kid uniqueness is paramount, as using the same kid for multiple clients and the same RS would have potentially disasterous consequences in that case. Similarly (though this is inherent to symmetric PoP and may not actually need reiterating), when we use symmetric PSKs for PoP, they lose almost all value if any given PSK is known to more than one client or RS. (The secdir review on the framework has us putting in MUST-level requirements to not share further than that, so it seems pretty reasonable to not duplicate that warning here.) This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework [I-D.ietf-ace-oauth-authz]. As it follows this framework's general approach, the general security considerations from section 6 also apply to this profile. (The HTMLized link will only do the right thing if you use the redundant "section 6 of [I-D.ietf-ace-oauth-authz]".) The use of multiple access tokens for a single client increases the strain on the resource server as it must consider every access token and calculate the actual permissions of the client. Also, tokens may contradict each other which may lead the server to enforce wrong permissions. If one of the access tokens expires earlier than others, the resulting permissions may offer insufficient protection. Developers SHOULD avoid using multiple access tokens for a client. I think I touched on this above; did we want to make a stronger statement about "only one active token per client"? Section 8 information as possible in an unencrypted response. When a DTLS session between the client and the resource server already exists, more detailed information MAY be included with an error response to provide the client with sufficient information to react on that particular error. I'd suggest adding a caveat like "an authenticated client" or "a known client", since DTLS itself does not guarantee that the client is not an attacker. Section 9 Profile ID: 1 I think this has to be merely a "suggested value", as IANA will control the actual allocations, in the absence of a reservation of this value in the framework document. Section 10.1 We don't currently reference RFC 7925 in any way that would require it to be a normative reference. We probably should, though -- somehow pull in that we require/recommend conformance with that profile of DTLS. Section 10.2 I think RFCs 7250, 7251, and 8422 need to be normative. Thanks, Ben From nobody Thu Jan 2 19:26:17 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 74BBF12004D; Thu, 2 Jan 2020 19:26:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ace-chairs@ietf.org, kaduk@mit.edu, mglt.ietf@gmail.com, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157802197540.3863.1567790717233417492.idtracker@ietfa.amsl.com> Date: Thu, 02 Jan 2020 19:26:15 -0800 Archived-At: Subject: [Ace] ace - New Meeting Session Request for IETF 107 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 03:26:16 -0000 A new meeting session request has just been submitted by Daniel Migault, a Chair of the ace working group. --------------------------------------------------------- Working Group Name: Authentication and Authorization for Constrained Environments Area Name: Security Area Session Requester: Daniel Migault Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 30 Conflicts to Avoid: Chair Conflict: cbor calext tmrid homenet lamps dnsop abcd Technology Overlap: teep lake tls oauth t2trg suit core cose Key Participant Conflict: secdispatch saag ipsecme acme cfrg lwig emu People who must be present: Daniel Migault Jim Schaad Benjamin Kaduk Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Jan 2 20:24:22 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B03E1200C1 for ; Thu, 2 Jan 2020 20:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKUKaYOVu887 for ; Thu, 2 Jan 2020 20:24:17 -0800 (PST) Received: from sjmda12.webex.com (sjmda12.webex.com [64.68.124.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 789911200B4 for ; Thu, 2 Jan 2020 20:24:17 -0800 (PST) Received: from rva2rmd101.webex.com (sjc02-wxpd-lb03-v140.webex.com [10.252.16.111]) by sjmda12.webex.com (Postfix) with ESMTP id 1946B302FEE1 for ; Fri, 3 Jan 2020 04:24:17 +0000 (GMT) Received: from rva2rmd101.webex.com (localhost [127.0.0.1]) by rva2rmd101.webex.com (Postfix) with ESMTP id BE888101BDE1 for ; Fri, 3 Jan 2020 04:24:16 +0000 (GMT) Date: Fri, 3 Jan 2020 04:24:16 +0000 (GMT) From: ACE Working Group Reply-To: ace-chairs@ietf.org To: ace@ietf.org Message-ID: <1871924156.4933601578025456778.JavaMail.nobody@rva2rmd101.webex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_986681_769066946.1578025456778" X-Priority: 3 Importance: normal X-WBX-INFO: X-WBX-SID=456680, X-WBX-CID=149229830315977957, X-WBX-TID=4vyaemk0csy00fu46c09x8vmgzlpoj6mzayk88effivqdsema2mvz31z, X-WBX-RID=ca6a80d883344293bd0ddb48af5e8ec6, X-WBX-SVC:Meeting Center, X-WBX-TT:Meeting Invitation, Date:Fri Jan 03 04:24:16 GMT 2020 reminder-39.10.0-2647 Archived-At: Subject: [Ace] Webex meeting invitation: ACE interim meeting X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2020 04:24:21 -0000 ------=_Part_986681_769066946.1578025456778 Content-Type: multipart/Alternative; boundary="----=_Part_986682_718400072.1578025456778" ------=_Part_986682_718400072.1578025456778 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhpLCBhY2VAaWV0Zi5vcmcsCgpBQ0UgV29ya2luZyBHcm91cCBpbnZpdGVzIHlvdSB0byBqb2lu IHRoaXMgV2ViZXggbWVldGluZy4KCgpBQ0UgaW50ZXJpbSBtZWV0aW5nCkZyaWRheSwgSmFudWFy eSAzMSwgMjAyMAoxMTowMCBhbSAgfCAgKFVUQy0wNTowMCkgRWFzdGVybiBUaW1lIChVUyAmIENh bmFkYSkgIHwgIDEgaHIgMzAgbWlucwpNZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDEg MDY2IDk5MiAKTWVldGluZyBwYXNzd29yZDogYWtaYVltZmYKCgoKV2hlbiBpdCdzIHRpbWUsIGpv aW4gdGhlIG1lZXRpbmcuCmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW04 OGZmMzZjY2FiMzhiNWUwNjVlNzg2NWMwNGJiYjI0MAoKQWRkIHRvIENhbGVuZGFyCmh0dHBzOi8v aWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1kYzI1M2U3NzRlOWE1OWQxZGUxYWNmYjRk Mzg1NTI5ZA0KDQoKCg0KSk9JTiBCWSBQSE9ORQ0KMS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xs IG51bWJlciAoVVMvQ2FuYWRhKQpUYXAgaGVyZSB0byBjYWxsIChtb2JpbGUgcGhvbmVzIG9ubHks IGhvc3RzIG5vdCBzdXBwb3J0ZWQpOiB0ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCowMSo2NDEwNjY5 OTIlMjMlMjMqMDEqCg0KDQoKSk9JTiBGUk9NIEEgVklERU8gU1lTVEVNIE9SIEFQUExJQ0FUSU9O CkRpYWwgc2lwOjY0MTA2Njk5MkBpZXRmLndlYmV4LmNvbQpZb3UgY2FuIGFsc28gZGlhbCAxNzMu MjQzLjIuNjggYW5kIGVudGVyIHlvdXIgbWVldGluZyBudW1iZXIuCgoKSm9pbiB1c2luZyBNaWNy b3NvZnQgTHluYyBvciBNaWNyb3NvZnQgU2t5cGUgZm9yIEJ1c2luZXNzCkRpYWwgc2lwOjY0MTA2 Njk5Mi5pZXRmQGx5bmMud2ViZXguY29tCgoKQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8KaHR0cHM6 Ly9jb2xsYWJvcmF0aW9uaGVscC5jaXNjby5jb20vYXJ0aWNsZS9XQlgwMDAwMjkwNTUKCgpJTVBP UlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViZXggc2VydmljZSBhbGxvd3Mg YXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJl IHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBC eSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNo IHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlz Y3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Np b24uCg== ------=_Part_986682_718400072.1578025456778 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PHN0eWxlIHR5cGU9InRleHQvY3NzIj4KKiB7CiAgICBwYWRkaW5nOiAwOyAgICBtYXJnaW46IDA7 fQp0YWJsZSB7Cglib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyB3aWR0aCA9MTAwJTsJYm9yZGVy OiAwOwlib3JkZXItc3BhY2luZzogMDt9Cgp0ciB7CglsaW5lLWhlaWdodDogMThweDt9CgphLCB0 ZCB7Cglmb250LXNpemU6IDE0cHg7CWZvbnQtZmFtaWx5OiBBcmlhbDsJY29sb3I6ICMzMzM7CXdv cmQtd3JhcDogYnJlYWstd29yZDsJd29yZC1icmVhazogbm9ybWFsOwlwYWRkaW5nOiAwO30KCi50 aXRsZSB7Cglmb250LXNpemU6IDI4cHg7fQoKLmltYWdlIHsKCXdpZHRoOiBhdXRvOwltYXgtd2lk dGg6IGF1dG87fQoKLmZvb3RlciB7Cgl3aWR0aDogNjA0cHg7fQoKLm1haW4gewoKfUBtZWRpYSBz Y3JlZW4gYW5kIChtYXgtZGV2aWNlLXdpZHRoOiA4MDBweCkgewoJLnRpdGxlIHsKCQlmb250LXNp emU6IDIycHggIWltcG9ydGFudDsJfQoJLmltYWdlIHsKCQl3aWR0aDogYXV0byAhaW1wb3J0YW50 OwkJbWF4LXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CX0KCS5mb290ZXIgewoJCXdpZHRoOiAxMDAl ICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFpbXBvcnRhbnQKCX0KCS5tYWluIHsKCQl3 aWR0aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50Cgl9Cn0K PC9zdHlsZT4KCjx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0icGFkZGluZzogMDsgbWFy Z2luOiAwOyBib3JkZXI6IDA7IHdpZHRoOiAxMDAlOyIgYWxpZ249ImxlZnQiPgoJPHRyIHN0eWxl PSJoZWlnaHQ6IDI4cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+Cgk8dHI+CgkJPHRkIGFsaWduPSJs ZWZ0IiBzdHlsZT0icGFkZGluZzogMCAyMHB4OyBtYXJnaW46IDAiPgoJCQk8IS0tPHRhYmxlIGJn Y29sb3I9IiNGRkZGRkYiIHN0eWxlPSJib3JkZXI6IDBweDsgd2lkdGg6IDEwMCU7IHBhZGRpbmct bGVmdDogNTBweDsgcGFkZGluZy1yaWdodDogNTBweDsiIGFsaWduPSJsZWZ0IiBjbGFzcz0ibWFp biI+CgkJCQk8dHI+CgkJCQkJPHRkIGFsaWduPSJjZW50ZXIiIHZhbGlnbj0idG9wIiA+Jm5ic3A7 CQkJCQk8L3RkPgoJCQkJPC90cj4KCQkJPC90YWJsZT4tLT4KCgo8dGFibGU+CiAgICAgICA8dHI+ CiAgICAgICAgICAgPHRkIHN0eWxlPSJoZWlnaHQ6IDIycHg7Y29sb3I6ICMwMDAwMDA7Zm9udC1m YW1pbHk6IEFyaWFsOwlmb250LXNpemU6IDE2cHg7Zm9udC13ZWlnaHQ6IGJvbGQ7bGluZS1oZWln aHQ6IDIycHg7Ij4KICAgICAgICAgICAgICAgIEFDRSBXb3JraW5nIEdyb3VwIGludml0ZXMgeW91 IHRvIGpvaW4gdGhpcyBXZWJleCBtZWV0aW5nLgogICAgICAgICAgICAgICAgCSAgICAgICAgICAg PC90ZD4KICAgICAgPC90cj4KPC90YWJsZT4KCgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdo dDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxl PgoKICAgIDx0YWJsZSBzdHlsZT0id2lkdGg6YXV0bzsgd2lkdGg6YXV0byFpbXBvcnRhbnQ7Ij4K ICAgICAgICA8dHI+CiAgICAgICAgICAgIDx0ZCBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsOyBj b2xvcjogIzAwMDAwMDsgZm9udC1zaXplOiAxNnB4OyBsaW5lLWhlaWdodDogMjJweDsiPgogICAg ICAgICAgICAgICAgTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogNjQxIDA2NiA5OTIKICAg ICAgICAgICAgPC90ZD4KICAgICAgICA8L3RyPgogICAgPC90YWJsZT4KICAgIDx0YWJsZSBzdHls ZT0id2lkdGg6YXV0bzsgd2lkdGg6YXV0byFpbXBvcnRhbnQiPgogICAgICAgIDx0ciA+CiAgICAg ICAgICAgIDx0ZCBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsOyBjb2xvcjogIzAwMDAwMDsgZm9u dC1zaXplOiAxNnB4OyBsaW5lLWhlaWdodDogMjJweDsiPk1lZXRpbmcgcGFzc3dvcmQ6IGFrWmFZ bWZmPC90ZD4KICAgICAgICA8L3RyPgogICAgPC90YWJsZT4KICAgICAgICAKPHRhYmxlPjx0ciBz dHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8 L3RkPjwvdHI+PC90YWJsZT4KCiAgICA8dGFibGUgIHdpZHRoPSIxMDAlIj4KICAgICAgICA8dHIg c3R5bGU9Im1hcmdpbjowcHg7Y29sb3I6ICM2NjY2NjY7Zm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQt c2l6ZTogMTRweDtsaW5lLWhlaWdodDogMjJweDsiPgogICAgICAgICAgICA8dGQgc3R5bGU9Im1h cmdpbjowcHg7Y29sb3I6ICM2NjY2NjY7Zm9udC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRw eDtsaW5lLWhlaWdodDogMjJweDsiPkZyaWRheSwgSmFudWFyeSAzMSwgMjAyMAogICAgICAgICAg ICA8L3RkPgogICAgICAgIDwvdHI+CiAgICAgICAgPHRyIHN0eWxlPSJtYXJnaW46MHB4O2NvbG9y OiAjNjY2NjY2O2ZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDE0cHg7bGluZS1oZWlnaHQ6 IDIycHg7Ij4KICAgICAgICAgICAgPHRkIHN0eWxlPSJtYXJnaW46MHB4O2NvbG9yOiAjNjY2NjY2 O2ZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDE0cHg7bGluZS1oZWlnaHQ6IDIycHg7Ij4x MTowMCBhbSZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDsoVVRDLTA1OjAwKSBFYXN0ZXJuIFRpbWUg KFVTICYgQ2FuYWRhKSZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDsxIGhyIDMwIG1pbnMKICAgICAg ICAgICAgPC90ZD4KICAgICAgICA8L3RyPgogICAgPC90YWJsZT4KCiA8Rk9OVCBzaXplPSIyIiBD T0xPUj0iI0ZGMDAwMCIgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsiPjwvRk9OVD4KCiAgICAK CgkJCTx0YWJsZSBzdHlsZT0icGFkZGluZy1ib3R0b206IDRweDtmb250LWZhbWlseTogQXJpYWw7 Ij48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4m bmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJPHRhYmxlIHN0eWxlPSd3aWR0aDphdXRvO3dpZHRo OmF1dG8haW1wb3J0YW50Oyc+PHRyPjx0ZCBzdHlsZT0nd2lkdGg6YXV0byFpbXBvcnRhbnQ7ICc+ PHRhYmxlIGJvcmRlcj0nMCcgY2VsbHBhZGRpbmc9JzAnIGNlbGxzcGFjaW5nPScwJyBzdHlsZT0n d2lkdGg6YXV0bzt3aWR0aDphdXRvIWltcG9ydGFudDsgYmFja2dyb3VuZC1jb2xvcjojNDNBOTQy OyBib3JkZXI6MHB4IHNvbGlkICM0M0E5NDI7IGJvcmRlci1yYWRpdXM6MjBweDsgbWluLXdpZHRo OjE2MHB4IWltcG9ydGFudDsnPjx0Ym9keT48dHI+PHRkIGFsaWduPSdjZW50ZXInIHN0eWxlPSdw YWRkaW5nOjEwcHggMzZweDtmb250LWZhbWlseTogQXJpYWw7Jz48YSBocmVmPSdodHRwczovL2ll dGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tODhmZjM2Y2NhYjM4YjVlMDY1ZTc4NjVjMDRi YmIyNDAnIHN0eWxlPSdjb2xvcjojRkZGRkZGOyBmb250LXNpemU6MjBweDsgdGV4dC1kZWNvcmF0 aW9uOm5vbmU7Jz5Kb2luIG1lZXRpbmc8L2E+PC90ZD48L3RyPjwvdGJvZHk+PC90YWJsZT48L3Rk PjwvdHI+PC90YWJsZT4KCQkJPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDQ4cHgiPjx0 ZCBzdHlsZT0iaGVpZ2h0OjQ4cHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoKCgk8dGFibGU+ PHRib2R5Pjx0cj48dGQgc3R5bGU9ImNvbG9yOiAjMDAwMDAwO2ZvbnQtZmFtaWx5OiBBcmlhbDsg Zm9udC1zaXplOiAxMnB4OyBmb250LXdlaWdodDogYm9sZDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij48 Yj5Kb2luIGJ5IHBob25lPC9iPjwvdGQ+PC90cj48dHI+PHRkIHN0eWxlPSJjb2xvcjogIzk5OTk5 OTtmb250LWZhbWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTJweDsgbGluZS1oZWlnaHQ6IDI0cHg7 Ij5UYXAgdG8gY2FsbCBpbiBmcm9tIGEgbW9iaWxlIGRldmljZSAoYXR0ZW5kZWVzIG9ubHkpPC90 ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkIHN0eWxlPSJjb2xvcjogIzMzMzMzMztm b250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0OiAyNHB4OyI+PGEg aHJlZj0ndGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqNjQxMDY2OTkyJTIzJTIzKjAxKicgc3R5 bGU9J2NvbG9yOiMwMEFGRjk7ICB0ZXh0LWRlY29yYXRpb246bm9uZTsgZm9udC1mYW1pbHk6IEFy aWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdodDogMjRweDsnPjEtNjUwLTQ3OS0zMjA4PC9h PiZuYnNwOzxzcGFuIHN0eWxlPSJjb2xvcjogIzMzMzMzMzsiPkNhbGwtaW4gdG9sbCBudW1iZXIg KFVTL0NhbmFkYSk8L3NwYW4+PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkIHN0 eWxlPSJmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0OiAyNHB4 OyI+PC90ZD48L3RyPjwvdGJvZHk+PC90YWJsZT48dGFibGUgY2VsbHBhZGRpbmc9IjAiIGNlbGxz cGFjaW5nPSIwIj48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyOHB4OyI+PHRkIHN0eWxlPSJoZWln aHQ6MjhweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+Cgk8dGFibGU+PHRyPjx0ZCAgc3R5bGU9 ImNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxMnB4OyBmb250 LXdlaWdodDogYm9sZDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij48Yj5Kb2luIGZyb20gYSB2aWRlbyBz eXN0ZW0gb3IgYXBwbGljYXRpb248L2I+PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+ PHRkIHN0eWxlPSJjb2xvcjogIzMzMzMzMzsgZm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6 IDE0cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+RGlhbCA8YSBocmVmPSIgc2lwOjY0MTA2Njk5MkBp ZXRmLndlYmV4LmNvbSIgICBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Y29sb3I6IzAwQUZG OSI+NjQxMDY2OTkyQGlldGYud2ViZXguY29tPC9hPjwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdp bjowcHgiPjx0ZCBzdHlsZT0iY29sb3I6ICMzMzMzMzM7IGZvbnQtZmFtaWx5OiBBcmlhbDsgZm9u dC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogMjRweDsiPllvdSBjYW4gYWxzbyBkaWFsIDE3My4y NDMuMi42OCBhbmQgZW50ZXIgeW91ciBtZWV0aW5nIG51bWJlci48L3RkPjwvdHI+PC90YWJsZT48 dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIw cHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgogICAgPHRhYmxlIGNlbGxwYWRkaW5nPSIwIiBj ZWxsc3BhY2luZz0iMCI+PHRyPjx0ZCAgc3R5bGU9ImNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWls eTogQXJpYWw7Zm9udC1zaXplOiAxMnB4OyBmb250LXdlaWdodDogYm9sZDsgbGluZS1oZWlnaHQ6 IDI0cHg7Ij48Yj5Kb2luIHVzaW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1pY3Jvc29mdCBTa3lwZSBm b3IgQnVzaW5lc3M8L2I+PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkIHN0eWxl PSJjb2xvcjogIzMzMzMzMzsgZm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDE0cHg7IGxp bmUtaGVpZ2h0OiAyNHB4OyI+RGlhbCA8YSBocmVmPSIgc2lwOjY0MTA2Njk5Mi5pZXRmQGx5bmMu d2ViZXguY29tIiAgIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtjb2xvcjojMDBBRkY5Ij42 NDEwNjY5OTIuaWV0ZkBseW5jLndlYmV4LmNvbTwvYT48L3RkPjwvdHI+PC90YWJsZT4KCgkJCTx0 YWJsZSBzdHlsZT0id2lkdGg6IDEwMCU7IiBhbGlnbj0ibGVmdCIgY2xhc3M9Im1haW4iPgogICAg ICAgICAgICAgICAgPHRyIHN0eWxlPSJoZWlnaHQ6IDcycHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+ CgkJCQk8dHI+CgkJCQkJPHRkIHN0eWxlPSJoZWlnaHQ6IDI0cHg7IGNvbG9yOiAjMDAwMDAwOyBm b250LWZhbWlseTpBcmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogMjRweDsiPk5l ZWQgaGVscD8gR28gdG8gPGEgaHJlZj0iaHR0cDovL2hlbHAud2ViZXguY29tIiBzdHlsZT0iY29s b3I6IzA0OUZEOTsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij5odHRwOi8vaGVscC53ZWJleC5jb208 L2E+CgkJCQkJPC90ZD4KCQkJCTwvdHI+CiAgICAgICAgICAgICAgICA8dHIgc3R5bGU9ImhlaWdo dDogNDRweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj4KCQkJPC90YWJsZT4KCQk8L3RkPgoJPC90cj4K PC90YWJsZT4K ------=_Part_986682_718400072.1578025456778 Content-Type: text/calendar;method=REQUEST;charset=utf-8; Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkFtZXJpY2EvTmV3X1lvcmsNClRaVVJMOmh0dHA6Ly90enVybC5vcmcvem9u ZWluZm8tb3V0bG9vay9BbWVyaWNhL05ld19Zb3JrDQpYLUxJQy1MT0NBVElPTjpBbWVyaWNhL05l d19Zb3JrDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wNTAwDQpUWk9GRlNFVFRPOi0w NDAwDQpUWk5BTUU6RURUDQpEVFNUQVJUOjE5NzAwMzA4VDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFS TFk7QllNT05USD0zO0JZREFZPTJTVQ0KRU5EOkRBWUxJR0hUDQpCRUdJTjpTVEFOREFSRA0KVFpP RkZTRVRGUk9NOi0wNDAwDQpUWk9GRlNFVFRPOi0wNTAwDQpUWk5BTUU6RVNUDQpEVFNUQVJUOjE5 NzAxMTAxVDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7QllNT05USD0xMTtCWURBWT0xU1UNCkVO RDpTVEFOREFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQU1QOjIwMjAwMTAz VDA0MjQxNloNCkFUVEVOREVFO0NOPSJhY2VAaWV0Zi5vcmciO1JPTEU9UkVRLVBBUlRJQ0lQQU5U O1JTVlA9VFJVRTpNQUlMVE86YWNlQGlldGYub3JnDQpPUkdBTklaRVI7Q049IkFDRSBXb3JraW5n IEdyb3VwIjpNQUlMVE86YWNlLWNoYWlyc0BpZXRmLm9yZw0KRFRTVEFSVDtUWklEPUFtZXJpY2Ev TmV3X1lvcms6MjAyMDAxMzFUMTEwMDAwDQpEVEVORDtUWklEPUFtZXJpY2EvTmV3X1lvcms6MjAy MDAxMzFUMTIzMDAwDQpMT0NBVElPTjpodHRwczovL2lldGYud2ViZXguY29tL2lldGYNClRSQU5T UDpPUEFRVUUNClNFUVVFTkNFOjE1NzgwMjU0NTYNClVJRDpjZmMzMDNkOS0wYmVkLTRkODQtYTMx Yi0yYTBhNjQ2ZWViMjMNCkRFU0NSSVBUSU9OOlxuXG5cblxuSk9JTiBXRUJFWCBNRUVUSU5HXG5o dHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tODhmZjM2Y2NhYjM4YjVlMDY1 ZTc4NjVjMDRiYmIyNDBcbk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDY0MSAwNjYgOTky XG5cblxuTWVldGluZyBwYXNzd29yZDogYWtaYVltZmZcblxuXG5cbkpPSU4gQlkgUEhPTkVcbjEt NjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlcblRhcCBoZXJlIHRv IGNhbGwgKG1vYmlsZSBwaG9uZXMgb25seSwgaG9zdHMgbm90IHN1cHBvcnRlZCk6IHRlbDolMkIx LTY1MC00NzktMzIwOCwsKjAxKjY0MTA2Njk5MiUyMyUyMyowMSpcblxuXG5cbkpPSU4gRlJPTSBB IFZJREVPIFNZU1RFTSBPUiBBUFBMSUNBVElPTlxuRGlhbCBzaXA6NjQxMDY2OTkyQGlldGYud2Vi ZXguY29tXG5Zb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVudGVyIHlvdXIgbWVl dGluZyBudW1iZXIuXG5cblxuSm9pbiB1c2luZyBNaWNyb3NvZnQgTHluYyBvciBNaWNyb3NvZnQg U2t5cGUgZm9yIEJ1c2luZXNzXG5EaWFsIHNpcDo2NDEwNjY5OTIuaWV0ZkBseW5jLndlYmV4LmNv bVxuXG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz9cbmh0dHBzOi8vY29sbGFib3JhdGlvbmhl bHAuY2lzY28uY29tL2FydGljbGUvV0JYMDAwMDI5MDU1XG5cblxuSU1QT1JUQU5UIE5PVElDRTog UGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYmV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhl ciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hp Y2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlz IHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJ ZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25j ZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLlxuDQpYLUFMVC1E RVNDO0ZNVFRZUEU9dGV4dC9odG1sOjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+XG4qIHtcbiAgICBw YWRkaW5nOiAwOyAgICBtYXJnaW46IDA7fVxudGFibGUge1xuCWJvcmRlci1jb2xsYXBzZTogc2Vw YXJhdGU7IHdpZHRoID0xMDAlOwlib3JkZXI6IDA7CWJvcmRlci1zcGFjaW5nOiAwO31cblxudHIg e1xuCWxpbmUtaGVpZ2h0OiAxOHB4O31cblxuYSwgdGQge1xuCWZvbnQtc2l6ZTogMTRweDsJZm9u dC1mYW1pbHk6IEFyaWFsOwljb2xvcjogIzMzMzsJd29yZC13cmFwOiBicmVhay13b3JkOwl3b3Jk LWJyZWFrOiBub3JtYWw7CXBhZGRpbmc6IDA7fVxuXG4udGl0bGUge1xuCWZvbnQtc2l6ZTogMjhw eDt9XG5cbi5pbWFnZSB7XG4Jd2lkdGg6IGF1dG87CW1heC13aWR0aDogYXV0bzt9XG5cbi5mb290 ZXIge1xuCXdpZHRoOiA2MDRweDt9XG5cbi5tYWluIHtcblxufUBtZWRpYSBzY3JlZW4gYW5kICht YXgtZGV2aWNlLXdpZHRoOiA4MDBweCkge1xuCS50aXRsZSB7XG4JCWZvbnQtc2l6ZTogMjJweCAh aW1wb3J0YW50Owl9XG4JLmltYWdlIHtcbgkJd2lkdGg6IGF1dG8gIWltcG9ydGFudDsJCW1heC13 aWR0aDogMTAwJSAhaW1wb3J0YW50Owl9XG4JLmZvb3RlciB7XG4JCXdpZHRoOiAxMDAlICFpbXBv cnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFpbXBvcnRhbnRcbgl9XG4JLm1haW4ge1xuCQl3aWR0 aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50XG4JfVxufVxu PC9zdHlsZT5cblxuPHRhYmxlIGJnY29sb3I9IiNGRkZGRkYiIHN0eWxlPSJwYWRkaW5nOiAwOyBt YXJnaW46IDA7IGJvcmRlcjogMDsgd2lkdGg6IDEwMCU7IiBhbGlnbj0ibGVmdCI+XG4JPHRyIHN0 eWxlPSJoZWlnaHQ6IDI4cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JPHRyPlxuCQk8dGQgYWxp Z249ImxlZnQiIHN0eWxlPSJwYWRkaW5nOiAwIDIwcHg7IG1hcmdpbjogMCI+XG4JCQk8IS0tPHRh YmxlIGJnY29sb3I9IiNGRkZGRkYiIHN0eWxlPSJib3JkZXI6IDBweDsgd2lkdGg6IDEwMCU7IHBh ZGRpbmctbGVmdDogNTBweDsgcGFkZGluZy1yaWdodDogNTBweDsiIGFsaWduPSJsZWZ0IiBjbGFz cz0ibWFpbiI+XG4JCQkJPHRyPlxuCQkJCQk8dGQgYWxpZ249ImNlbnRlciIgdmFsaWduPSJ0b3Ai ID4mbmJzcDsJCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCTwvdGFibGU+LS0+XG5cblxuXG5cblxu CQkJPHRhYmxlPlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJCQkJPEZPTlQgU0laRT0iNCIgQ09M T1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5XaGVuIGl0J3MgdGltZSwgam9pbiB0aGUgV2ViZXgg bWVldGluZyBoZXJlLjwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJCTx0ciBzdHls ZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3Rk PjwvdHI+XG4JCQkJPHRyPlxuCQkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0i IzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDY0MSAw NjYgOTkyPC9GT05UPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQk8L3RhYmxlPlxuCQkJXG4J CQk8dGFibGU+PHRyPjx0ZD48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJp YWwiPk1lZXRpbmcgcGFzc3dvcmQ6PC9GT05UPjwvdGQ+PHRkPjxGT05UIFNJWkU9IjIiICBDT0xP Uj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPmFrWmFZbWZmPC9GT05UPjwvdGQ+PC90cj48L3RhYmxl PlxuXG4gICAgICAgIDx0YWJsZT5cbiAgICAgICAgCTx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIw cHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+XG4JCQk8dHI+XG4J CQkJPHRkIHN0eWxlPSJ3aWR0aDphdXRvIWltcG9ydGFudDsgIj5cbgkJCQkJPHRhYmxlIGJvcmRl cj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIiBzdHlsZT0id2lkdGg6YXV0bzt3 aWR0aDphdXRvIWltcG9ydGFudDtiYWNrZ3JvdW5kLWNvbG9yOiM0M0E5NDI7IGJvcmRlcjowcHgg c29saWQgIzQzQTk0MjsgYm9yZGVyLXJhZGl1czoyNXB4OyBtaW4td2lkdGg6MTYwcHghaW1wb3J0 YW50OyI+XG4JCQkJCQk8dHI+XG4JCQkJCQkJPHRkIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJwYWRk aW5nOjEwcHggMzZweDsiPjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBo cD9NVElEPW04OGZmMzZjY2FiMzhiNWUwNjVlNzg2NWMwNGJiYjI0MCIgc3R5bGU9ImNvbG9yOiNG RkZGRkY7IGZvbnQtc2l6ZToyMHB4OyB0ZXh0LWRlY29yYXRpb246bm9uZTsiPkpvaW4gbWVldGlu ZzwvYT48L3RkPlxuCQkJCQkJPC90cj5cbgkJCQkJPC90YWJsZT5cbgkJCQk8L3RkPlxuCQkJPC90 cj5cbgkJPC90YWJsZT5cblxuIDxGT05UIHNpemU9IjIiIENPTE9SPSIjRkYwMDAwIiBzdHlsZT0i Zm9udC1mYW1pbHk6IEFyaWFsOyI+PC9GT05UPlxuPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwi PiZuYnNwOzxCUj4mbmJzcDs8QlI+PC9GT05UPlxuXG4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjQi IEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwi PkpvaW4gYnkgcGhvbmU8L0ZPTlQ+ICZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2 NjY2NjYiIEZBQ0U9ImFyaWFsIj48Yj48YSBocmVmPSd0ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCow MSo2NDEwNjY5OTIlMjMlMjMqMDEqJyBzdHlsZT0nY29sb3I6IzAwQUZGOTsgIHRleHQtZGVjb3Jh dGlvbjpub25lOyBmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0 OiAyNHB4Oyc+MS02NTAtNDc5LTMyMDg8L2E+PC9iPiBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9D YW5hZGEpPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+PC9GT05UPiZuYnNwOyA8QlI+PEJSPjxCUj5cblxuPHRhYmxlPjx0ciBzdHls ZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3Rk PjwvdHI+PC90YWJsZT5cblxuPEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9 IjMiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBmcm9tIGEgdmlkZW8gc3lzdGVt IG9yIGFwcGxpY2F0aW9uPC9GT05UPjxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIg RkFDRT0iYXJpYWwiPkRpYWw8L0ZPTlQ+IDxhIGhyZWY9InNpcDo2NDEwNjY5OTJAaWV0Zi53ZWJl eC5jb20iPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJhcmlhbCI+NjQxMDY2 OTkyQGlldGYud2ViZXguY29tPC9GT05UPjwvYT4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENP TE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+WW91IGNhbiBhbHNvIGRpYWwgMTczLjI0My4yLjY4 IGFuZCBlbnRlciB5b3VyIG1lZXRpbmcgbnVtYmVyLjwvRk9OVD4gJm5ic3A7IDxCUj48L0ZPTlQ+ Jm5ic3A7IDxCUj5cblxuPHRhYmxlIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCI+PHRy Pjx0ZCAgc3R5bGU9ImNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXpl OiAxMnB4OyBmb250LXdlaWdodDogYm9sZDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij48Yj5Kb2luIHVz aW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1pY3Jvc29mdCBTa3lwZSBmb3IgQnVzaW5lc3M8L2I+PC90 ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkIHN0eWxlPSJjb2xvcjogIzMzMzMzMzsg Zm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+ RGlhbCA8YSBocmVmPSIgc2lwOjY0MTA2Njk5Mi5pZXRmQGx5bmMud2ViZXguY29tIiAgIHN0eWxl PSJ0ZXh0LWRlY29yYXRpb246bm9uZTtjb2xvcjojMDBBRkY5Ij42NDEwNjY5OTIuaWV0ZkBseW5j LndlYmV4LmNvbTwvYT48L3RkPjwvdHI+PC90YWJsZT5cblxuCQkJPHRhYmxlIHN0eWxlPSJ3aWR0 aDogMTAwJTsiIGFsaWduPSJsZWZ0IiBjbGFzcz0ibWFpbiI+XG4gICAgICAgICAgICAgICAgPHRy IHN0eWxlPSJoZWlnaHQ6IDcycHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JCQkJPHRyPlxuCQkJ CQk8dGQgc3R5bGU9ImhlaWdodDogMjRweDsgY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OkFy aWFsOyBmb250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+TmVlZCBoZWxwPyBHbyB0 byA8YSBocmVmPSJodHRwOi8vaGVscC53ZWJleC5jb20iIHN0eWxlPSJjb2xvcjojMDQ5RkQ5OyB0 ZXh0LWRlY29yYXRpb246bm9uZTsiPmh0dHA6Ly9oZWxwLndlYmV4LmNvbTwvYT5cbgkJCQkJPC90 ZD5cbgkJCQk8L3RyPlxuICAgICAgICAgICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0OiA0NHB4Ij48 dGQ+Jm5ic3A7PC90ZD48L3RyPlxuCQkJPC90YWJsZT5cbgkJPC90ZD5cbgk8L3RyPlxuPC90YWJs ZT5cbg0KU1VNTUFSWTpBQ0UgaW50ZXJpbSBtZWV0aW5nDQpQUklPUklUWTo1DQpDTEFTUzpQVUJM SUMNCkJFR0lOOlZBTEFSTQ0KVFJJR0dFUjotUFQ1TQ0KQUNUSU9OOkRJU1BMQVkNCkRFU0NSSVBU SU9OOlJlbWluZGVyDQpFTkQ6VkFMQVJNDQpFTkQ6VkVWRU5UDQpFTkQ6VkNBTEVOREFSDQo= ------=_Part_986682_718400072.1578025456778-- ------=_Part_986681_769066946.1578025456778 Content-Type: application/octet-stream; name="Webex_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Webex_Meeting.ics" QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkFtZXJpY2EvTmV3X1lvcmsNClRaVVJMOmh0dHA6Ly90enVybC5vcmcvem9u ZWluZm8tb3V0bG9vay9BbWVyaWNhL05ld19Zb3JrDQpYLUxJQy1MT0NBVElPTjpBbWVyaWNhL05l d19Zb3JrDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wNTAwDQpUWk9GRlNFVFRPOi0w NDAwDQpUWk5BTUU6RURUDQpEVFNUQVJUOjE5NzAwMzA4VDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFS TFk7QllNT05USD0zO0JZREFZPTJTVQ0KRU5EOkRBWUxJR0hUDQpCRUdJTjpTVEFOREFSRA0KVFpP RkZTRVRGUk9NOi0wNDAwDQpUWk9GRlNFVFRPOi0wNTAwDQpUWk5BTUU6RVNUDQpEVFNUQVJUOjE5 NzAxMTAxVDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7QllNT05USD0xMTtCWURBWT0xU1UNCkVO RDpTVEFOREFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQU1QOjIwMjAwMTAz VDA0MjQxNloNCkFUVEVOREVFO0NOPSJhY2VAaWV0Zi5vcmciO1JPTEU9UkVRLVBBUlRJQ0lQQU5U O1JTVlA9VFJVRTpNQUlMVE86YWNlQGlldGYub3JnDQpPUkdBTklaRVI7Q049IkFDRSBXb3JraW5n IEdyb3VwIjpNQUlMVE86YWNlLWNoYWlyc0BpZXRmLm9yZw0KRFRTVEFSVDtUWklEPUFtZXJpY2Ev TmV3X1lvcms6MjAyMDAxMzFUMTEwMDAwDQpEVEVORDtUWklEPUFtZXJpY2EvTmV3X1lvcms6MjAy MDAxMzFUMTIzMDAwDQpMT0NBVElPTjpodHRwczovL2lldGYud2ViZXguY29tL2lldGYNClRSQU5T UDpPUEFRVUUNClNFUVVFTkNFOjE1NzgwMjU0NTYNClVJRDpjZmMzMDNkOS0wYmVkLTRkODQtYTMx Yi0yYTBhNjQ2ZWViMjMNCkRFU0NSSVBUSU9OOlxuXG5cblxuSk9JTiBXRUJFWCBNRUVUSU5HXG5o dHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tODhmZjM2Y2NhYjM4YjVlMDY1 ZTc4NjVjMDRiYmIyNDBcbk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDY0MSAwNjYgOTky XG5cblxuTWVldGluZyBwYXNzd29yZDogYWtaYVltZmZcblxuXG5cbkpPSU4gQlkgUEhPTkVcbjEt NjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlcblRhcCBoZXJlIHRv IGNhbGwgKG1vYmlsZSBwaG9uZXMgb25seSwgaG9zdHMgbm90IHN1cHBvcnRlZCk6IHRlbDolMkIx LTY1MC00NzktMzIwOCwsKjAxKjY0MTA2Njk5MiUyMyUyMyowMSpcblxuXG5cbkpPSU4gRlJPTSBB IFZJREVPIFNZU1RFTSBPUiBBUFBMSUNBVElPTlxuRGlhbCBzaXA6NjQxMDY2OTkyQGlldGYud2Vi ZXguY29tXG5Zb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVudGVyIHlvdXIgbWVl dGluZyBudW1iZXIuXG5cblxuSm9pbiB1c2luZyBNaWNyb3NvZnQgTHluYyBvciBNaWNyb3NvZnQg U2t5cGUgZm9yIEJ1c2luZXNzXG5EaWFsIHNpcDo2NDEwNjY5OTIuaWV0ZkBseW5jLndlYmV4LmNv bVxuXG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz9cbmh0dHBzOi8vY29sbGFib3JhdGlvbmhl bHAuY2lzY28uY29tL2FydGljbGUvV0JYMDAwMDI5MDU1XG5cblxuSU1QT1JUQU5UIE5PVElDRTog UGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYmV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhl ciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hp Y2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlz IHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJ ZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25j ZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLlxuDQpYLUFMVC1E RVNDO0ZNVFRZUEU9dGV4dC9odG1sOjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+XG4qIHtcbiAgICBw YWRkaW5nOiAwOyAgICBtYXJnaW46IDA7fVxudGFibGUge1xuCWJvcmRlci1jb2xsYXBzZTogc2Vw YXJhdGU7IHdpZHRoID0xMDAlOwlib3JkZXI6IDA7CWJvcmRlci1zcGFjaW5nOiAwO31cblxudHIg e1xuCWxpbmUtaGVpZ2h0OiAxOHB4O31cblxuYSwgdGQge1xuCWZvbnQtc2l6ZTogMTRweDsJZm9u dC1mYW1pbHk6IEFyaWFsOwljb2xvcjogIzMzMzsJd29yZC13cmFwOiBicmVhay13b3JkOwl3b3Jk LWJyZWFrOiBub3JtYWw7CXBhZGRpbmc6IDA7fVxuXG4udGl0bGUge1xuCWZvbnQtc2l6ZTogMjhw eDt9XG5cbi5pbWFnZSB7XG4Jd2lkdGg6IGF1dG87CW1heC13aWR0aDogYXV0bzt9XG5cbi5mb290 ZXIge1xuCXdpZHRoOiA2MDRweDt9XG5cbi5tYWluIHtcblxufUBtZWRpYSBzY3JlZW4gYW5kICht YXgtZGV2aWNlLXdpZHRoOiA4MDBweCkge1xuCS50aXRsZSB7XG4JCWZvbnQtc2l6ZTogMjJweCAh aW1wb3J0YW50Owl9XG4JLmltYWdlIHtcbgkJd2lkdGg6IGF1dG8gIWltcG9ydGFudDsJCW1heC13 aWR0aDogMTAwJSAhaW1wb3J0YW50Owl9XG4JLmZvb3RlciB7XG4JCXdpZHRoOiAxMDAlICFpbXBv cnRhbnQ7CQltYXgtd2lkdGg6IDYwNHB4ICFpbXBvcnRhbnRcbgl9XG4JLm1haW4ge1xuCQl3aWR0 aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50XG4JfVxufVxu PC9zdHlsZT5cblxuPHRhYmxlIGJnY29sb3I9IiNGRkZGRkYiIHN0eWxlPSJwYWRkaW5nOiAwOyBt YXJnaW46IDA7IGJvcmRlcjogMDsgd2lkdGg6IDEwMCU7IiBhbGlnbj0ibGVmdCI+XG4JPHRyIHN0 eWxlPSJoZWlnaHQ6IDI4cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JPHRyPlxuCQk8dGQgYWxp Z249ImxlZnQiIHN0eWxlPSJwYWRkaW5nOiAwIDIwcHg7IG1hcmdpbjogMCI+XG4JCQk8IS0tPHRh YmxlIGJnY29sb3I9IiNGRkZGRkYiIHN0eWxlPSJib3JkZXI6IDBweDsgd2lkdGg6IDEwMCU7IHBh ZGRpbmctbGVmdDogNTBweDsgcGFkZGluZy1yaWdodDogNTBweDsiIGFsaWduPSJsZWZ0IiBjbGFz cz0ibWFpbiI+XG4JCQkJPHRyPlxuCQkJCQk8dGQgYWxpZ249ImNlbnRlciIgdmFsaWduPSJ0b3Ai ID4mbmJzcDsJCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCTwvdGFibGU+LS0+XG5cblxuXG5cblxu CQkJPHRhYmxlPlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJCQkJPEZPTlQgU0laRT0iNCIgQ09M T1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5XaGVuIGl0J3MgdGltZSwgam9pbiB0aGUgV2ViZXgg bWVldGluZyBoZXJlLjwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuCQkJCTx0ciBzdHls ZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3Rk PjwvdHI+XG4JCQkJPHRyPlxuCQkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0i IzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDY0MSAw NjYgOTkyPC9GT05UPlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQk8L3RhYmxlPlxuCQkJXG4J CQk8dGFibGU+PHRyPjx0ZD48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJp YWwiPk1lZXRpbmcgcGFzc3dvcmQ6PC9GT05UPjwvdGQ+PHRkPjxGT05UIFNJWkU9IjIiICBDT0xP Uj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPmFrWmFZbWZmPC9GT05UPjwvdGQ+PC90cj48L3RhYmxl PlxuXG4gICAgICAgIDx0YWJsZT5cbiAgICAgICAgCTx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIw cHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+XG4JCQk8dHI+XG4J CQkJPHRkIHN0eWxlPSJ3aWR0aDphdXRvIWltcG9ydGFudDsgIj5cbgkJCQkJPHRhYmxlIGJvcmRl cj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIiBzdHlsZT0id2lkdGg6YXV0bzt3 aWR0aDphdXRvIWltcG9ydGFudDtiYWNrZ3JvdW5kLWNvbG9yOiM0M0E5NDI7IGJvcmRlcjowcHgg c29saWQgIzQzQTk0MjsgYm9yZGVyLXJhZGl1czoyNXB4OyBtaW4td2lkdGg6MTYwcHghaW1wb3J0 YW50OyI+XG4JCQkJCQk8dHI+XG4JCQkJCQkJPHRkIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJwYWRk aW5nOjEwcHggMzZweDsiPjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBo cD9NVElEPW04OGZmMzZjY2FiMzhiNWUwNjVlNzg2NWMwNGJiYjI0MCIgc3R5bGU9ImNvbG9yOiNG RkZGRkY7IGZvbnQtc2l6ZToyMHB4OyB0ZXh0LWRlY29yYXRpb246bm9uZTsiPkpvaW4gbWVldGlu ZzwvYT48L3RkPlxuCQkJCQkJPC90cj5cbgkJCQkJPC90YWJsZT5cbgkJCQk8L3RkPlxuCQkJPC90 cj5cbgkJPC90YWJsZT5cblxuIDxGT05UIHNpemU9IjIiIENPTE9SPSIjRkYwMDAwIiBzdHlsZT0i Zm9udC1mYW1pbHk6IEFyaWFsOyI+PC9GT05UPlxuPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwi PiZuYnNwOzxCUj4mbmJzcDs8QlI+PC9GT05UPlxuXG4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjQi IEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwi PkpvaW4gYnkgcGhvbmU8L0ZPTlQ+ICZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2 NjY2NjYiIEZBQ0U9ImFyaWFsIj48Yj48YSBocmVmPSd0ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCow MSo2NDEwNjY5OTIlMjMlMjMqMDEqJyBzdHlsZT0nY29sb3I6IzAwQUZGOTsgIHRleHQtZGVjb3Jh dGlvbjpub25lOyBmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0 OiAyNHB4Oyc+MS02NTAtNDc5LTMyMDg8L2E+PC9iPiBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9D YW5hZGEpPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+PC9GT05UPiZuYnNwOyA8QlI+PEJSPjxCUj5cblxuPHRhYmxlPjx0ciBzdHls ZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3Rk PjwvdHI+PC90YWJsZT5cblxuPEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9 IjMiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBmcm9tIGEgdmlkZW8gc3lzdGVt IG9yIGFwcGxpY2F0aW9uPC9GT05UPjxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIg RkFDRT0iYXJpYWwiPkRpYWw8L0ZPTlQ+IDxhIGhyZWY9InNpcDo2NDEwNjY5OTJAaWV0Zi53ZWJl eC5jb20iPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJhcmlhbCI+NjQxMDY2 OTkyQGlldGYud2ViZXguY29tPC9GT05UPjwvYT4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENP TE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+WW91IGNhbiBhbHNvIGRpYWwgMTczLjI0My4yLjY4 IGFuZCBlbnRlciB5b3VyIG1lZXRpbmcgbnVtYmVyLjwvRk9OVD4gJm5ic3A7IDxCUj48L0ZPTlQ+ Jm5ic3A7IDxCUj5cblxuPHRhYmxlIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCI+PHRy Pjx0ZCAgc3R5bGU9ImNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXpl OiAxMnB4OyBmb250LXdlaWdodDogYm9sZDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij48Yj5Kb2luIHVz aW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1pY3Jvc29mdCBTa3lwZSBmb3IgQnVzaW5lc3M8L2I+PC90 ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkIHN0eWxlPSJjb2xvcjogIzMzMzMzMzsg Zm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+ RGlhbCA8YSBocmVmPSIgc2lwOjY0MTA2Njk5Mi5pZXRmQGx5bmMud2ViZXguY29tIiAgIHN0eWxl PSJ0ZXh0LWRlY29yYXRpb246bm9uZTtjb2xvcjojMDBBRkY5Ij42NDEwNjY5OTIuaWV0ZkBseW5j LndlYmV4LmNvbTwvYT48L3RkPjwvdHI+PC90YWJsZT5cblxuCQkJPHRhYmxlIHN0eWxlPSJ3aWR0 aDogMTAwJTsiIGFsaWduPSJsZWZ0IiBjbGFzcz0ibWFpbiI+XG4gICAgICAgICAgICAgICAgPHRy IHN0eWxlPSJoZWlnaHQ6IDcycHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JCQkJPHRyPlxuCQkJ CQk8dGQgc3R5bGU9ImhlaWdodDogMjRweDsgY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFtaWx5OkFy aWFsOyBmb250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+TmVlZCBoZWxwPyBHbyB0 byA8YSBocmVmPSJodHRwOi8vaGVscC53ZWJleC5jb20iIHN0eWxlPSJjb2xvcjojMDQ5RkQ5OyB0 ZXh0LWRlY29yYXRpb246bm9uZTsiPmh0dHA6Ly9oZWxwLndlYmV4LmNvbTwvYT5cbgkJCQkJPC90 ZD5cbgkJCQk8L3RyPlxuICAgICAgICAgICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0OiA0NHB4Ij48 dGQ+Jm5ic3A7PC90ZD48L3RyPlxuCQkJPC90YWJsZT5cbgkJPC90ZD5cbgk8L3RyPlxuPC90YWJs ZT5cbg0KU1VNTUFSWTpBQ0UgaW50ZXJpbSBtZWV0aW5nDQpQUklPUklUWTo1DQpDTEFTUzpQVUJM SUMNCkJFR0lOOlZBTEFSTQ0KVFJJR0dFUjotUFQ1TQ0KQUNUSU9OOkRJU1BMQVkNCkRFU0NSSVBU SU9OOlJlbWluZGVyDQpFTkQ6VkFMQVJNDQpFTkQ6VkVWRU5UDQpFTkQ6VkNBTEVOREFSDQo= ------=_Part_986681_769066946.1578025456778-- From nobody Fri Jan 3 20:37:09 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E92120103; Fri, 3 Jan 2020 20:37:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQFAS8lVlWbA; Fri, 3 Jan 2020 20:37:04 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4127A120058; Fri, 3 Jan 2020 20:37:03 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 3 Jan 2020 20:36:56 -0800 From: Jim Schaad To: 'Benjamin Kaduk' , CC: References: <20200102234020.GI35479@kduck.mit.edu> In-Reply-To: <20200102234020.GI35479@kduck.mit.edu> Date: Fri, 3 Jan 2020 20:36:54 -0800 Message-ID: <014601d5c2b8$9947acc0$cbd70640$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHGCRF5nmwiv9SPGwzqJ8qbQfLFcKf5StjQ Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2020 04:37:07 -0000 -----Original Message----- From: Benjamin Kaduk =20 Sent: Thursday, January 2, 2020 3:40 PM To: draft-ietf-ace-dtls-authorize.all@ietf.org Cc: ace@ietf.org Subject: AD review of draft-ietf-ace-dtls-authorize-09 Hi all, Some high-level remarks before delving into the section-by-section comments: This document is pretty clearly DTLS 1.2-specific -- it talks about = particular protocol messages, message fields, and cipher suites that = simply do not apply to DTLS 1.3. In order to use this profile with DTLS = 1.3, we'd need to specify the analogous behavior/requirements to these = (including standalone signature schemes and key-exchange groups, which = are now both separately negotiated from the cipher suite). Given that DTLS 1.3 is past WGLC and only a few documents behind this = one in my review queue, it seems fairly prudent to spend some time and = cover how DTLS 1.3 would work here, since otherwise this document will = become stale shortly after (or even before!) its publication as an RFC. [JLS] Yes we need to look at this, but we also know who's fault this is = =F0=9F=98=89 Part of me wants to punt this off to the CoRE working = group because the way they are currently using DTLS 1.2 is quite = restrictive and they really need to do a DTLS 1.3 document. There's probably some additional discussion to include about the usage = of key identifiers in this document versus the potential uses described = in the core framework. Specifically, the framework reminds us that "no = assumptions should be made that it is unique in the domains of either = the client or the RS" yet this document is using the kid as input to a = KDF that produces keys that must be unique across all clients, and = allowing live/instant authorization updates based on matching "kid". How shall we resolve this apparent conflict? [JLS] I am having a problem seeing what the conflict is here. The "kid" = is a publicly known value so that fact that it is included in the KDF is = not what is going to produce unique keys for all clients no matter what. = It is the secret that is going to make things unique. There is a = potential problem with the fact that the RS may get two different = entities that register a token which has the same kid value, but that is = a known issue for (D)TLS. This is one of the reasons that the token = itself can be used as the "kid" for DTLS. We also are potentially in violation of the framework's requirements = with respect to the independent selection of profiles for client/AS and = client/RS interactions -- at present, when DTLS+RPK is used for = client/RS, we require that DTLS+RPK is also used for client/AS, in order = to prove possession of the key. We could perhaps weasel our way out by = saying that the framework's requirement applies at the profile = granularity, and with symmetric PSK we can be fully independent, but we = still need to say something about this property and the interaction with = the framework's requirements. [JLS] I am missing where it is saying this. Can you give a pointer? I = don't believe that the POP of the RPK is required at the time that the = token is obtained. This profile is mostly applicable to the client/RS communications and = feels like it only provides some of the picture for use with client/AS = interactions. (It doesn't really say much of anything about RS/AS interactions.) The introductory discussion does not do a great job of = painting that picture, and I'd like to see it more clearly introduced = that the bulk of our coverage is for the client/RS interaction. We also = lean heavily on the existing out-of-band configuration and key material = shared between client and AS to secure the client/AS communications; we = could probably tighten up the discussion about exactly what parameters = of client/AS communication are specified by this profile. [JLS] I think this makes sense. We do not say anything about DTLS session resumption (or renegotiation, = though not talking about that one is perfectly fine); that's a fairly = core DTLS concept that we should give some guidance on. [JLS] I don't see any reason to talk about renegotiation, either it is = done or it isn't and a new connection would need to be created. I am = not sure what to say about session resumption. This is something that = really needs to be dealt with in the CoRE working group before anything = can be said here. Session resumption would only resume the TLS session, = but any CoRE state above it is not going to be restored because it is = defined as going away in RFC 7252. This is currently also true for = doing a renegotiation. Looking through Appendix C ("Requirements on Profiles") of the = framework, do we want to say anything about: - using the client credentials grant with this profile, as that's IIRC the only example we show - require that DTLS be used in a mode that provides replay protection - when the client uses the authz-info endpoint instead of the "psk_identity" field to convey the token to the RS, how does the RS know which client is connecting (and thus what PSK to use), and what does the client actually *put* in the "psk_identity" field? (The other aspects of "how to select a proof-of-possession protocol" seem to fall out naturally from the DTLS usage.) - whether/how introspection is used? - give more details of what this profile mandates when used for client/AS interactions (as mentioned above) - explicitly state that the authz-info endpoint is unprotected (or that it might be protected if, e.g., the RS has a trustable certificate that would be used instead of RPK or PSK, or by supplying the token as the "psk_identity" when symmetric PoP is used, or by only doing server-authentication with RPK as known by the client by the rs_cnf access information And now, on to the section-by-section comments. Section 1 a DTLS session. The communication between client and authorization server may also be secured with DTLS. This specification supports DTLS with Raw Public Keys (RPK) [RFC7250] and with Pre-Shared Keys (PSK) [RFC4279]. [DTLS 1.3 will inherit TLS 1.3's built-in support for (so-called "external") PSKs.] The DTLS handshake requires the client and server to prove that they can use certain keying material. In the RPK mode, the client proves with the DTLS handshake that it can use the RPK bound to the token and the server shows that it can use a certain RPK. The access token must be presented to the resource server. For the RPK mode, the access token needs to be uploaded to the resource server before the handshake is initiated, as described in Section 5.8.1 of the ACE framework [I-D.ietf-ace-oauth-authz]. This seems to be making some implicit assumptions about the message flow = that have not yet been covered by this document and are only somewhat = covered by the core framework spec. I'd propose: % The ACE framework requires that client and server mutually % = authenticate each other before any other protocol exchanges take % = place. In order for DTLS to provide mutual authentication, both % = client and server must prove their ability to use certain keying % = material (tied to the authenticated identity) as part of the DTLS % = handshake. The AS assists in this process by incorporating key % = material (or information about key material) into the access token, % = which is considered a "proof of possession" token. In the RPK mode, % = the client proves that it can use the RPK bound to the token and the % = server shows that it can use a certain RPK (as indicated by the AS to % = the client). The resource server needs access to the token in order % = to complete this exchange. For the RPK mode, the access token needs % = to be uploaded to the resource server before the handshake is % = initiated, as described in Section 5.8.1 of the ACE framework % = [I-D.ietf-ace-oauth-authz]. though I recognize that my text tends to be a bit more verbose than is = strictly needed, so please feel free to edit it down. Section 2 The CoAP-DTLS profile for ACE specifies the transfer of authentication information and, if necessary, authorization information between the client (C) and the resource server (RS) during setup of a DTLS session for CoAP messaging. It also specifies how C can use CoAP over DTLS to retrieve an access token from the authorization server (AS) for a protected resource hosted on the resource server. I suggest reiterating that "As specified in Section 6.7 of = [I-D.ietf-ace-oauth-authz], use of DTLS for one or both of these = interactions is completely independent". To determine the AS in charge of a resource hosted at the RS, C MAY send an initial Unauthorized Resource Request message to the RS. The This is part of the core framework, so the "MAY" may be overkill. (Lowercase "can" would do just fine.) Once the client knows the authorization server's address, it can send an access token request to the token endpoint at the AS as specified Hmm. There's some level of "the client needs to have already been = configured that that AS is a valid AS" verification that's done here, = but I'm not sure if that's too much detail to include at this stage = (since we're really just summarizing the framework here). in [I-D.ietf-ace-oauth-authz]. As the access token request as well as the response may contain confidential data, the communication between the client and the authorization server MUST be (This "MUST" is already a requirement from the core framework, so we = don't necessarily need to repeat it as normative language.) confidentiality-protected and ensure authenticity. C may have been registered at the AS via the OAuth 2.0 client registration mechanism as outlined in Section 5.3 of [I-D.ietf-ace-oauth-authz]. Section 5.3 of oauth-authz says that registration is "out of scope"; is = this still the right reference? [I-D.ietf-ace-oauth-authz]. In case the client uses a symmetric proof-of-possession key in the DTLS handshake, the procedure as above MAY be used, or alternatively, the access token MAY instead be transferred in the DTLS ClientKeyExchange message (see Section 3.3.1). (This is not DTLS 1.3-compatible.) Section 3 secured. Depending on the used CoAP security mode (see also Section 9 of [RFC7252], the Client-to-AS request, AS-to-Client response and DTLS session establishment carry slightly different information. [...] At this point in the document it's pretty unclear what "Client-to-AS = request", "AS-to-Client response", and "DTLS session establishment" are = and how they relate to each other. Also, it seems like the behavior in Section 3.2 and 3.3 are relating to = the mode used for the client/RS interactions, which relates to the = client/AS interactions only in the form of how PoP information is bound = to/with the token. Section 3.1 establish a secure communication channel. C MUST securely have obtained keying material to communicate with AS. Furthermore, C MUST verify that AS is authorized to provide access tokens (including authorization information) about RS to C. Also, AS MUST securely have obtained keying material for C, and obtained authorization rules approved by the resource owner (RO) concerning C and RS that relate to this keying material. [...] The way this is written right now, we're going to get lots of questions = from reviewers about "how does this happen?" and for more details about = it. We are effectively assuming that this stuff is all provisioned = already as part of the device configuration or during enrollment, we = should say something about these being requirements on device = provisioning, not on the operation of the ACE protocol. between C and AS is bootstrapped is not part of this document. C and AS MUST ensure the confidentiality, integrity and authenticity of all exchanged messages. I think this is also restating requirements from the core framework, and = may not need normative language in this manner. Section 3.2 I know that the section heading says "RawPublicKey Mode" already, but = I'd recommend adding a sentence in the preface that repeats that "When = the client and RS use RawPublicKey authentication, the procedure is as = follows"; we might get complaints otherwise that we are saying that the = client MUST do things that are not universal requirements. (Section 3.3 does already have something like this for the symmetric-key case.) previously made known to the authorization server. To prove that the client is in possession of this key, C MUST use the same keying material that it uses to secure the communication with AS, e.g., the DTLS session. This seems in conflict with the core framework's requirement that the = client/AS profile and client/RS profile are severable. AS MUST check if the client that it communicates with is associated with the RPK in the cnf object before issuing an access token to it. Earlier in the section we noted a requirement to prove possession of the = key by using it in DTLS; why is there a separate "association" requirement? also, nit: "The AS". which case it does not have to be sent. The response also contains an access token and an "rs_cnf" parameter containing information about the public key that is used by the resource server. AS MUST nit(?): is the "rs_cnf" parameter always mandatory? (Or only when = DTLS-RPK is used for client-RS interactions?) nit: "The AS" again (and throughought, to a large extent). server that C wants to communicate with. AS MUST protect the integrity of the token. If the access token contains confidential data, AS MUST also protect the confidentiality of the access token. This requirement ("protect the integrity of the token") feels a little = underspecified, as it doesn't say protection over what workflow or who = will verify the integrity (the RS). C MUST ascertain that the access token response belongs to a certain previously sent access token request, as the request may specify the resource server with which C wants to communicate. nit: I recomment rewording "belongs to", perhaps as "corresponds to". DTLS can provide this guarantee when configured to do so, though it is = not a guaranteed property from DTLS. We'll probably get some grief about the "access_token" contents in the = example not being valid CBOR, due to the parenthetical comment. We = could probably put a note in the preface that the value is truncated for = readability. Also, nit: "the client's" with article and apostrophe. Section 3.2.1 Before the client initiates the DTLS handshake with the resource server, C MUST send a "POST" request containing the new access token to the authz-info resource hosted by the resource server. After the client nit: we don't require single-use tokens, so "new" is probably overkill; = just "its access token" should suffice. nit: formatting issue with spurious line break here. server. To use the RawPublicKey mode, the client MUST specify the public key that AS defined in the "cnf" field of the access token response in the SubjectPublicKeyInfo structure in the DTLS handshake as specified in [RFC7250]. IIRC the access token response does not have to include a "cnf" field = (e.g., if the AS accepts the req_cnf from the request), so "defined in = the field of the response" doesn't seem like quite the right wording. An implementation that supports the RPK mode of this profile MUST at least support the ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 I understand that making the full-width-tag ciphersuite MTI would = exclude some devices, though it feels like some recommendation to use = the full-length tag when possible would be appropriate. That said, I do = see that RFC 7252 makes no such remark, and thus consistency would have = us not say anything either. [RFC7251] with the ed25519 curve (cf. [RFC8032], [RFC8422]). Just to be clear: ed25519 is an ECDSA algorithm; the corresponding ECDHE = operation is called x25519, and both algorithms make use of the = elliptical curve known as curve25519. Since we are using both ECDHE and = ECDSA, it's probably simplest to just refer to "curve25519", though = mentioning both ed25519 and x25519 would also work. RS MUST check if the access token is still valid, if RS is the intended destination, i.e., the audience, of the token, and if the token was issued by an authorized AS. The access token is nit: "i.e., the audience" is in effect a parenthetical, so using commas = to offset it inside a comma-separated list is potentially confusing; I'd = suggest using actual parentheses instead of commas around it. reference to this key. If the authorization server has no certain knowledge that the Client's key is already known to the resource server, the Client's public key MUST be included in the access token's "cnf" parameter. If CBOR web tokens [RFC8392] are used as recommended in [I-D.ietf-ace-oauth-authz], keys MUST be encoded as specified in [I-D.ietf-ace-cwt-proof-of-possession]. RS MUST use the Is talking about """the access token's "cnf" parameter" consistent with = allowing the use of non-CWT (non-JWT) token formats? keying material in the handshake that AS specified in the rs_cnf parameter in the access token. Thus, the handshake only finishes if C and RS are able to use their respective keying material. I suggest being explicit about "the DTLS handshake with the client", = perhaps as "MUST use in the DLTS handshake with the client the keying = material that the AS specified in the rs_cnf parameter in the access = token". The same caveat about "parameter in the access token" applies here, though I guess there is an additional complication for = "rs_cnf" in that it's an token response parameter but I don't remember = that we say a huge amount about it also being included in the token = itself -- the token response is directed to the client but the token is = directed to the RS. Section 3.3 token. AS MUST check if the identifier refers to a symmetric key that was previously generated by AS as a shared secret for the communication between this client and the resource server. "What does the AS do if this check fails?" The authorization server MUST determine the authorization rules for the C it communicates with as defined by RO and generate the access nit: it's surprising to see "authorization server" spelled out in the = same sentence as "C" and "RO" (which, incidentally, we don't seem to use = in abbreviation form anywhere other than where we define it). wants to communicate with. Also, AS MUST protect the integrity of the access token. If the token contains confidential data such as the symmetric key, the confidentiality of the token MUST also be protected. Depending on the requested token type and algorithm in (same comment about "protect the integrity" or "protect" as for the RPK case.) that is to be used between C and the resource server. The access token MUST be bound to the same symmetric key by means of the cnf claim. Now we call it a "claim" rather than a "token parameter", but this again = seems to be implicitly assuming CWT/JWT for tokens. (Also, this "MUST" seems like something that the framework should = guarantee and not a new requirement that the DTLS profile imposes.) Figure 5: Example Access Token Request, symmetric PoP-key Maybe we could include "(implicit)" in the caption, since symmetric PoP = key is the default. An example access token response is illustrated in Figure 6. In this Is it accurate to say "A corresponding example access token response"? It's nice to the reader if we can tie the examples together like that. Is the "Max-Age" usage in Figure 6 typical? (Also, similar comment = about having the parenthetical comment in the example body vs. preface.) token_type : pop, Didn't we switch this to being capitalized as "PoP"? "COSE_Encrypt0" structure. The AS MUST use the keying material shared with the RS to encrypt the token. nit: I suggest s/shared with/it shares with/ We should probably say something about why the kid in Figure 7 is = different from the one in Figure 6. 4.00 Bad Request Content-Format: application/ace+cbor Payload: { error : invalid_request } Figure 8: Example Access Token Response With Reject RFC 6749's description of "invalid_request" seems to imply that it's = mostly about malformed requests, as opposed to the AS deciding that the = client is not authorized for any access to the requested resource (which = is maybe what's implied by the previous paragraph). This is not = necessarily a problem, but perhaps we could make the text and example = more consistent. The method for how the resource server determines the symmetric key from an access token containing only a key identifier is application specific, the remainder of this section provides one example. nit: hyphenate "application-specific", and this is a comma splice. resource server. This key needs to be securely stored and processed in the same way as the key used to protect the communication between AS and RS. nit: is this better as "processed" or "protected"? The fields in the context information "COSE_KDF_Context" (Section 11.2 of [RFC8152]) have the following values: o AlgorithmID =3D "ACE-CoAP-DTLS-key-derivation" RFC 8152 says that these AlgorithmID values come from the COSE = Algorithms registry, which this does not (unless we register it there, = which we don't currently). Also, since the output is used directly for = DTLS PSK, I don't think the "key-derivation" portion is needed. o PartyUInfo =3D PartyVInfo =3D ( null, null, null ) (8152 seems to prefer "nil" over "null".) o keyDataLength needs to be defined by the application o protected MUST be a zero length bstr o other is a zero length bstr (These three are all members of the "SuppPubInfo" field, which is not = very clear from how we include them in the same list as top-level fields.) Section 3.3.1 When a client receives an access token response from an authorization server, C MUST ascertain that the access token response belongs to a certain previously sent access token request, as the request may specify the resource server with which C wants to communicate. (Same bit about "belongs to".) If a resource server receives a ClientKeyExchange message that contains a "psk_identity" with a length greater zero, it uses the contents as index for its key store (i.e., treat the contents as key (This is not DTLS 1.3-compatible.) nits: "greater than", "as an index", "as a key identifier" identifier). The resource server MUST check if it has one or more access tokens that are associated with the specified key. I don't understand this sentence -- isn't the access token the precise = contents of the "psk_identity" field, so that there would be a key = associated with the access token, not the other way around? If no key with a matching identifier is found, the resource server MAY process the contents of the "psk_identity" field as access token Similarly here, the causality feels reversed. continuing the DTLS handshake. If the contents of the "psk_identity" do not yield a valid access token for the requesting client, the DTLS session setup is terminated with an "illegal_parameter" DTLS alert message. I think "the RS aborts the DTLS handshake with an 'illegal_parameter' = alert" would be more conventional phrasing. Note2: According to [RFC7252], CoAP implementations MUST support the ciphersuite TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]. A client is therefore expected to offer at least this ciphersuite to the resource server. Do we want to say anything about the (EC)DHE variants? Short-lived = access tokens with the AS generating new symmetric keys can provide = similar forward-secrecy properties to using DHE, but there is in general = a trend in the IETF towards defaulting to providing forward secrecy in = key exchanges. When RS receives an access token, RS MUST check if the access token is still valid, if RS is the intended destination, i.e., the audience of the token, and if the token was issued by an authorized AS. This As above, "i.e., the audience of the token" would probably be better = when offset in parentheses than by commas. While the client can retrieve the shared secret from the contents of the "cnf" parameter in the AS-to-Client response, the resource server uses the information contained in the "cnf" claim of the access token to determine the actual secret when no explicit "kid" was provided in the "psk_identity" field. If key derivation is used, the RS uses the "COSE_KDF_Context" information as described above. "psk_identity" is a field in ClientKeyExchange, and we say that its = contents are the raw access token for our usage. It does not have a = direct COSE structure for this talk of "kid" to make much sense without = further explanation. Section 3.4 We may get some requests for a more explicit definition of what the = "authorization information" tied to a client is. Once a DTLS channel has been established as described in Section 3.2 and Section 3.3, respectively, the client is authorized to access nit: I think "or" is more appropriate to join the sections listed, as = only one is applicable to a given connection. With the successful establishment of the DTLS channel, C and RS have proven that they can use their respective keying material. An access token that is bound to the client's keying material is associated with the channel. Any request that the resource server receives on this channel MUST be checked against these authorization rules. RS nit: I'd s/these/the following/ MUST check for every request if the access token is still valid. Incoming CoAP requests that are not authorized with respect to any access token that is associated with the client MUST be rejected by the resource server with 4.01 response as described in Section 5.1.1 of [I-D.ietf-ace-oauth-authz]. "any access token" implies there might be more than one, though I seem = to recall discussion of updated tokens overwriting any previous one, so = that only one token per client is active at any given time. What did we = end up settling on? Also, the referenced framework Section 5.1.1 does not actually mandate = the 4.01 response code. The resource server SHOULD treat an incoming CoAP request as authorized if the following holds: We could say more about this "SHOULD" (or change the way we discuss it) -- is it the minimum baseline of checks and additional checks may be = applied, or do some of them not apply in some cases, or ...? Incoming CoAP requests received on a secure DTLS channel that are not thus authorized MUST be rejected according to Section 5.8.2 of [I-D.ietf-ace-oauth-authz] We may also get some questions asking about what the difference is = between the "not authorized with respect to any access token" in the = previous quoted snippet" and "not thus authorized" in this quoted = snippet. The client cannot always know a priori if an Authorized Resource Request will succeed. It MUST check the validity of its keying material before sending a request or processing a response. If the What does "check the validity of its keying material" mean? client repeatedly gets error responses containing AS Creation Hints (cf. Section 5.1.2 of [I-D.ietf-ace-oauth-authz] as response to its requests, it SHOULD request a new access token from the authorization server in order to continue communication with the resource server. Why should this only be done in the case of *repeatedly* getting such = error responses; I thought the idea of the AS Request Creation Hints was = to take immediate effect. (Also, nit: s/AS Creation Hints/AS Request Creation Hints/.) Section 4 The client can update the authorization information stored at the resource server at any time without changing an established DTLS session. To do so, the Client requests a new access token from the authorization server for the intended action on the respective resource and uploads this access token to the authz-info resource on the resource server. I suggest adding another sentence similar to "Because ACE tokens are = proof-of-possession tokens, the updated authorization information only = takes immediate effect if such proof has already been provided, e.g., if = the PoP key associated with the new token is the same as the one = currently in use." This is further detailed in the following = paragraphs, but not stated concretely as a key principle. Section 5 DTLS sessions that have been established in accordance with this profile are always tied to a specific access token. As this token Doesn't the dynamic authorization update mechanism allow that token to = be swapped out during the lifetime of the connection? Also, as a terminology point, I think "DTLS association" is more = appropriate than "DTLS session" for what we describe, since the token is = is tied to the client and consulted at the start of the handshake, as = opposed to being a property of the DTLS session and carried across = resumptions. may become invalid at any time (e.g. because it has expired), the session may become useless at some point. A resource server therefore MUST terminate existing DTLS sessions after the access token for this session has been deleted. I assume that using "been deleted" vs. "has expired" is a deliberate = choice? If we don't say anything else about when to delete tokens, it = doesn't post much of a requirement, though. Section 6 endpoint. The use of CoAP and DTLS for this communication is RECOMMENDED in this profile, other protocols (such as HTTP and TLS or CoAP and OSCORE) MAY be used instead. nit: comma splice Also, we could potentially refer to the OSCORE profile document here = (informatively). If other means of securing the communication with the AS are used, the security protocol MUST fulfill the communication security requirements in Section 6.2 of [I-D.ietf-ace-oauth-authz]. I suggest phrasing more like "the communication security requirements = from Section 6.2 of [I-D.ietf-ace-oauth-authz] remain applicable", since = there's no need to add another MUST to the ones already in the framework = document. Section 7 I have a few suggestions for potential additions to this section as well = as comments on the existing contents. We might consider adding a brief note about the use of 8-byte = authentication tags in DTLS ciphers and how that affects the risk = profile. The use of "live" authorization upgrades on an existing DTLS connection = by posting a new token to the authz-info endpoint does not provide much = guarantee about the order in which operations occur (and thus which = authorization info is used to process a given client request), = especially in the face of an attacker that can delay and reorder = packets. This does not necessarily mean that we should not bother to = define that mechanism, but we should point out that there is only a weak = ordering property provided, note that other mechanisms should be used = when strict serialization is important, and caution that when the = later-issued token contains a reduction in authorization from the = initial token, it is impossible to guarantee that the reduction in = authorization will take effect prior to the expiration of the original = token. We rely heavily on the AS to accurately provide binding of raw key = material to authorization information and endpoint identinty; I think = this is a stronger reliance than just that implied by the core = architecture, and so might merit a mention here. (This relates to all = the checks about "MUST check that [client/...] is associated with = [RPK/PSK]" that appear throughout the document.) I'd also suggest reiterating all the places where we rely on out-of-band = configuration, as there's always a risk of such configuration becoming = stale (or getting attacked directly). I'd consider reiterating that when the KDF scheme is in use between RS = and AS, that kid uniqueness is paramount, as using the same kid for = multiple clients and the same RS would have potentially disasterous = consequences in that case. Similarly (though this is inherent to symmetric PoP and may not actually = need reiterating), when we use symmetric PSKs for PoP, they lose almost = all value if any given PSK is known to more than one client or RS. (The = secdir review on the framework has us putting in MUST-level requirements = to not share further than that, so it seems pretty reasonable to not = duplicate that warning here.) This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework [I-D.ietf-ace-oauth-authz]. As it follows this framework's general approach, the general security considerations from section 6 also apply to this profile. (The HTMLized link will only do the right thing if you use the redundant = "section 6 of [I-D.ietf-ace-oauth-authz]".) The use of multiple access tokens for a single client increases the strain on the resource server as it must consider every access token and calculate the actual permissions of the client. Also, tokens may contradict each other which may lead the server to enforce wrong permissions. If one of the access tokens expires earlier than others, the resulting permissions may offer insufficient protection. Developers SHOULD avoid using multiple access tokens for a client. I think I touched on this above; did we want to make a stronger = statement about "only one active token per client"? Section 8 information as possible in an unencrypted response. When a DTLS session between the client and the resource server already exists, more detailed information MAY be included with an error response to provide the client with sufficient information to react on that particular error. I'd suggest adding a caveat like "an authenticated client" or "a known = client", since DTLS itself does not guarantee that the client is not an = attacker. Section 9 Profile ID: 1 I think this has to be merely a "suggested value", as IANA will control = the actual allocations, in the absence of a reservation of this value in = the framework document. Section 10.1 We don't currently reference RFC 7925 in any way that would require it = to be a normative reference. We probably should, though -- somehow pull = in that we require/recommend conformance with that profile of DTLS. Section 10.2 I think RFCs 7250, 7251, and 8422 need to be normative. Thanks, Ben From nobody Sat Jan 4 06:27:18 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 943C9120241; Sat, 4 Jan 2020 06:27:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <157814803152.14430.2900815753681662838@ietfa.amsl.com> Date: Sat, 04 Jan 2020 06:27:11 -0800 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-pubsub-profile-00.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2020 14:27:11 -0000 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 : Pub-Sub Profile for Authentication and Authorization for Constrained Environments (ACE) Author : Francesca Palombini Filename : draft-ietf-ace-pubsub-profile-00.txt Pages : 19 Date : 2020-01-04 Abstract: This specification defines an application profile for authentication and authorization for publishers and subscribers in a pub-sub setting scenario in a constrained environment, using the ACE framework. This profile relies on transport layer or application layer security to authorize the publisher to the broker. Moreover, it relies on application layer security for publisher-broker and subscriber-broker communication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-pubsub-profile/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-pubsub-profile-00 https://datatracker.ietf.org/doc/html/draft-ietf-ace-pubsub-profile-00 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/ From nobody Sat Jan 4 06:33:45 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E949812023E for ; Sat, 4 Jan 2020 06:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTThK_Tj8cJp for ; Sat, 4 Jan 2020 06:33:41 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2052.outbound.protection.outlook.com [40.107.22.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 352FA12022A for ; Sat, 4 Jan 2020 06:33:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RbGX6j7VLtet8jLoUhFQnAtPRagJr3Wp/3EmWbhj6Ow4Fzbpy+rNysATP648f7UumGl0Tk/on4bY5P7uapkR57/axNxSVETAPY1g5Kb10ACn8BVRZr2+mFWkXgmGXI+Fjgp9sBG3EbDBmLLfsLuuAGo4VMhrQK5pZ5FZhYSVLhvnXetDtqQ5HIWCSbHvSwcTEo0GzapEHi93NbLOmrACpCoZD6jp0WZB1TCcSXrL5OVpIEOwQzRukE8x2R+N6p1bfntQ7HgEGMEHdJkL0zWinAqtVEMYp5CbMk4BByGVQ1aBiTcPvR26a6NfwePfUu2UbzmRDK6ejzKnX0DsyVUhqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DVQAts/AytVYtDMfMRgkM4FD1wNp7qkUZdekBu5Wa+g=; b=KnGgdpfGBLLFlzI3nzQCp+gzekAy1SWSu90pO2fKcvaaaWrupoC4LlnCrjQS7e76ULUKPwOdPUUEwuYBPWj/B2DkDeGs6HmJc7AyJ5pjFlSl5iH6i/5ZOhmOq7sb5TFKvullL17/4SdGifXptxN4FObGwPCKUz1IB5edCUlEcvYgrsv6XeACgq5+pjWpuyJ4w1LtH5QPgaxtqZOzT/fFx1kAWcAvDMPUhV4VDljiXHIRmHyLKg1/XehnRtvbk6WfAfrle71Af6fI37fXl3sXtXAQKnp9X9TM72bBnHG9T3SEjAzxzVG03qKlAftyIyxAWVqtk5QjuBRzAXyxEKP2Jg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DVQAts/AytVYtDMfMRgkM4FD1wNp7qkUZdekBu5Wa+g=; b=jhMoUsG95vaV1He2hmKlWrMcRz4yullM/nt/ybuoVIS7WOwlZBGdJtJGAoE3WghB84YKcBUUR1JHN1EXB7kQ2U0KPGwNb1nDEUzjbmY8tLYTYaxkHe3RdRxU9pfmYBlXdRoAcYyh8kNvB5xcYYhzvGpj7QLGjRvFerNTLi63oxg= Received: from AM6PR07MB4053.eurprd07.prod.outlook.com (52.134.117.139) by AM6PR07MB4534.eurprd07.prod.outlook.com (20.176.243.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.4; Sat, 4 Jan 2020 14:33:38 +0000 Received: from AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::ad29:1208:e331:71cc]) by AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::ad29:1208:e331:71cc%3]) with mapi id 15.20.2623.002; Sat, 4 Jan 2020 14:33:38 +0000 From: Francesca Palombini To: Daniel Migault CC: Ace Wg , Cigdem Sengul Thread-Topic: [Ace] Call for adoption draft-palombini-ace-coap-pubsub-profile Thread-Index: AQHVnrWn369e3fEdOECJBetALv7aeqfE+dYAgAI6Q4CAE7cmAA== Date: Sat, 4 Jan 2020 14:33:38 +0000 Message-ID: References: <7456FFE2-F792-452A-9DA1-5DEA078CECE0@ericsson.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [2.34.132.79] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 24281736-fff2-4e90-62ca-08d7912316cc x-ms-traffictypediagnostic: AM6PR07MB4534: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 02723F29C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(376002)(136003)(366004)(39860400002)(199004)(189003)(316002)(53546011)(54906003)(6506007)(33656002)(36756003)(478600001)(966005)(86362001)(8676002)(66946007)(66476007)(76116006)(66556008)(6486002)(4326008)(66446008)(2906002)(91956017)(6512007)(81166006)(64756008)(71200400001)(2616005)(81156014)(8936002)(66574012)(5660300002)(44832011)(26005)(9326002)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB4534; H:AM6PR07MB4053.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BQtLVAw57u6GB+rzwbjv5FRydASlJi+FTsuNMUa5I0NfCn01pQeCw9ObPI77ZdAZUvEEClJ4ZgSDQIVI9Yy1t+nCiJkMrRnEDbtTvFO2X/PBlQ3mAegIdTZKMElZgpmXW7afzbMt94PAEgR8vedq7FRySHRvn2ztlKvDXY2dArDIcRDukuAeCyHCJKga2Q5RWsYpUasUDX/Hj54pQWu++vY74W40Ux83vkT/frAOKSChFIKLmMJw58PCfhJ13YzntKLJ12Icc2TjSrp8hZSsHOv7dqgc7dJjmuFPeGjrOkG2TUSBo2LDuJWcDidlrHZloIPqq9Uz8kOW+3tPXUBIVWSFMKTLV9pzfx6XsBRT8mz8YDSIdXsmqNk2AZb/vaB6UHgf1JA/BbZRmGSvOjvtuEyhfv8Q3BWMZ9SJTNmndO7dQH7Np9k8UldGU6e/3sXLIfQmrCLtM+pan/zrJKN1uUC/ve1qPFkYTIzFTWpbPFf8I5L/asqTA6BfHdWlLA4BdmdO6CjCEi00w3m9SVgBkQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_D840FBD06CEE449BAD2CF37BB96D6D38ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 24281736-fff2-4e90-62ca-08d7912316cc X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2020 14:33:38.8101 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ivymcAs7t9H5PhVi7qm4xJGIw6uVYZtHnXwvampHrdvy8HUCmH/ebuQrEjcGHLbK9i6iFao6knCGX/mfO/h7IwvZtjWDkEYTwXYd0GG9q7TE6DXYUouZpE2bPxy78Jh+ X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB4534 Archived-At: Subject: Re: [Ace] Call for adoption draft-palombini-ace-coap-pubsub-profile X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2020 14:33:44 -0000 --_000_D840FBD06CEE449BAD2CF37BB96D6D38ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoYW5rcywgZG9uZSBqdXN0IG5vdy4gUGxlYXNlIG5vdGUgdGhhdDoNCg0KDQogICog ICBJIHBpY2tlZCB0aGUgbmFtZSDigJxkcmFmdC1pZXRmLWFjZS1wdWJzdWItcHJvZmlsZeKAnSBh bmQgZHJvcHBpbmcg4oCcY29hcOKAnSwgZm9sbG93aW5nIHRoZSBkaXNjdXNzaW9uIGFuZCBpbiB2 aWV3IG9mIHRoZSB1cGRhdGVzIHBsYW5uZWQsIHdoZXJlIE1RVFQgd2lsbCBiZSBjb25zaWRlcmVk IGFzIHdlbGwuIE5hbWUgY2FuIG9mIGNvdXJzZSBiZSByZWNvbnNpZGVyZWQgaWYgYW55Ym9keSBo YXMgYSBiZXR0ZXIgaWRlYS4NCiAgKiAgIFRoZSBkcmFmdCBpdHNlbGYgaGFzIG5vdCBiZWVuIHVw ZGF0ZWQgd2l0aCB0aGUgcGxhbm5lZCBjaGFuZ2VzLiBJIHdpbGwgZ2V0IGJhY2sgdG8gaXQgYXMg c29vbiBhcyBJIGFtIGJhY2sgZnJvbSB2YWNhdGlvbi4NCg0KSGFwcHkgbmV3IHllYXIhDQpGcmFu Y2VzY2ENCg0KLS0NCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1hY2UtcHVi c3ViLXByb2ZpbGUtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEZy YW5jZXNjYSBQYWxvbWJpbmkgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0K TmFtZTogICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1hY2UtcHVic3ViLXByb2ZpbGUNClJl dmlzaW9uOiAgICAgICAgICAgICAgMDANClRpdGxlOiAgICAgICAgICAgICAgICAgICAgICBQdWIt U3ViIFByb2ZpbGUgZm9yIEF1dGhlbnRpY2F0aW9uIGFuZCBBdXRob3JpemF0aW9uIGZvciBDb25z dHJhaW5lZCBFbnZpcm9ubWVudHMgKEFDRSkNCkRvY3VtZW50IGRhdGU6ICAgICAgICAgICAgICAg IDIwMjAtMDEtMDQNCkdyb3VwOiAgICAgICAgICAgICAgICAgIGFjZQ0KUGFnZXM6ICAgICAgICAg ICAgICAgICAgIDE5DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWlldGYtYWNlLXB1YnN1Yi1wcm9maWxlLTAwLnR4dA0KU3RhdHVzOiAg ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYWNlLXB1 YnN1Yi1wcm9maWxlLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWFjZS1wdWJzdWItcHJvZmlsZS0wMA0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1hY2UtcHVic3ViLXBy b2ZpbGUNCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGFuIGFw cGxpY2F0aW9uIHByb2ZpbGUgZm9yIGF1dGhlbnRpY2F0aW9uDQogICBhbmQgYXV0aG9yaXphdGlv biBmb3IgcHVibGlzaGVycyBhbmQgc3Vic2NyaWJlcnMgaW4gYSBwdWItc3ViIHNldHRpbmcNCiAg IHNjZW5hcmlvIGluIGEgY29uc3RyYWluZWQgZW52aXJvbm1lbnQsIHVzaW5nIHRoZSBBQ0UgZnJh bWV3b3JrLiAgVGhpcw0KICAgcHJvZmlsZSByZWxpZXMgb24gdHJhbnNwb3J0IGxheWVyIG9yIGFw cGxpY2F0aW9uIGxheWVyIHNlY3VyaXR5IHRvDQogICBhdXRob3JpemUgdGhlIHB1Ymxpc2hlciB0 byB0aGUgYnJva2VyLiAgTW9yZW92ZXIsIGl0IHJlbGllcyBvbg0KICAgYXBwbGljYXRpb24gbGF5 ZXIgc2VjdXJpdHkgZm9yIHB1Ymxpc2hlci1icm9rZXIgYW5kIHN1YnNjcmliZXItYnJva2VyDQog ICBjb21tdW5pY2F0aW9uLg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUg aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3Jn Lg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCkZyb206IERhbmllbCBNaWdhdWx0IDxkYW5p ZWwubWlnYXVsdD00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz4NCkRhdGU6IE1vbmRheSwg MjMgRGVjZW1iZXIgMjAxOSBhdCAwMzoyOQ0KVG86IEZyYW5jZXNjYSBQYWxvbWJpbmkgPGZyYW5j ZXNjYS5wYWxvbWJpbmlAZXJpY3Nzb24uY29tPg0KQ2M6IERhbmllbCBNaWdhdWx0IDxkYW5pZWwu bWlnYXVsdEBlcmljc3Nvbi5jb20+LCBBY2UgV2cgPGFjZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbQWNlXSBDYWxsIGZvciBhZG9wdGlvbiBkcmFmdC1wYWxvbWJpbmktYWNlLWNvYXAtcHVic3Vi LXByb2ZpbGUNCg0KSGksDQoNCllvdSBhcmUgY29ycmVjdCwgdGhlIGNhbGwgaGFzIGV4cGlyZWQu IFBsZWFzZSB1cGxvYWQgdGhlIGRvY3VtZW50IGFzIGEgV0cgZG9jdW1lbnQhDQoNCllvdXJzLA0K RGFuaWVsDQoNCk9uIFNhdCwgRGVjIDIxLCAyMDE5IGF0IDEwOjI4IEFNIEZyYW5jZXNjYSBQYWxv bWJpbmkgPGZyYW5jZXNjYS5wYWxvbWJpbmk9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc8 bWFpbHRvOjQwZXJpY3Nzb24uY29tQGRtYXJjLi5pZXRmLm9yZz4+IHdyb3RlOg0KSGksDQoNClRo aXMgYWRvcHRpb24gY2FsbCBoYXMgZW5kZWQgYSB3aGlsZSBhZ28sIEkgYW0gd2FpdGluZyBmb3Ig YSBjb25jbHVzaW9uIGJlZm9yZSBzdWJtaXR0aW5nIHRoZSBuZXh0IHZlcnNpb24gb2YgdGhlIGRv Y3VtZW50LCBhbHNvIGluIHZpZXcgb2YgbmV4dCBpbnRlcmltLg0KDQpIb3BlIHlvdSBoYXZlIGEg aGFwcHkgbmV3IHllYXIgY2VsZWJyYXRpb24sDQpGcmFuY2VzY2ENCg0KRnJvbTogQWNlIDxhY2Ut Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86YWNlLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYg b2YgRGFuaWVsIE1pZ2F1bHQgPGRhbmllbC5taWdhdWx0PTQwZXJpY3Nzb24uY29tQGRtYXJjLmll dGYub3JnPG1haWx0bzo0MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz4+DQpEYXRlOiBUdWVz ZGF5LCAxOSBOb3ZlbWJlciAyMDE5IGF0IDA5OjQ1DQpUbzogQWNlIFdnIDxhY2VAaWV0Zi5vcmc8 bWFpbHRvOmFjZUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBbQWNlXSBDYWxsIGZvciBhZG9wdGlvbiBk cmFmdC1wYWxvbWJpbmktYWNlLWNvYXAtcHVic3ViLXByb2ZpbGUNCg0KRGVhciB3b3JraW5nIGdy b3VwLA0KDQpBcyBtZW50aW9uZWQgZHVyaW5nIHRoZSBBQ0UgbWVldGluZywgdGhpcyBtYWlsIHN0 YXJ0cyBhIGNhbGwgZm9yIGFkb3B0aW9uIGZvciBkcmFmdC1wYWxvbWJpbmktYWNlLWNvYXAtcHVi c3ViLXByb2ZpbGUuIFBsZWFzZSBwcm92aWRlIHlvdXIgZmVlZCBiYWNrcyBieSBEZWNlbWJlciA0 Lg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wYWxvbWJpbmktYWNl LWNvYXAtcHVic3ViLXByb2ZpbGUvDQoNCllvdXJzLA0KRGFuaWVsDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBY2UgbWFpbGluZyBsaXN0DQpBY2VA aWV0Zi5vcmc8bWFpbHRvOkFjZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vYWNlDQo= --_000_D840FBD06CEE449BAD2CF37BB96D6D38ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <226AE3559E5FD7468423D9AC68A3B2C6@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2 Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6 MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxl ZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIu MHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8q IExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE4NzA2MDQ0MzI7 DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNzI1NjU1 OTE4IC04OTY2NDY1NDggMTM0ODA3NTU1IDEzNDgwNzU1NyAxMzQ4MDc1NTMgMTM0ODA3NTU1IDEz NDgwNzU1NyAxMzQ4MDc1NTMgMTM0ODA3NTU1IDEzNDgwNzU1Nzt9DQpAbGlzdCBsMDpsZXZlbDEN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMDpsZXZlbDIN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30N CnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhhbmtzLCBkb25lIGp1c3Qgbm93LiBQbGVhc2Ug bm90ZSB0aGF0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBjbSIgdHlwZT0iZGlzYyI+DQo8bGkg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzEiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ SSBwaWNrZWQgdGhlIG5hbWUg4oCcZHJhZnQtaWV0Zi1hY2UtcHVic3ViLXByb2ZpbGXigJ0gYW5k IGRyb3BwaW5nIOKAnGNvYXDigJ0sIGZvbGxvd2luZyB0aGUgZGlzY3Vzc2lvbiBhbmQgaW4gdmll dyBvZiB0aGUgdXBkYXRlcyBwbGFubmVkLCB3aGVyZSBNUVRUDQogd2lsbCBiZSBjb25zaWRlcmVk IGFzIHdlbGwuIE5hbWUgY2FuIG9mIGNvdXJzZSBiZSByZWNvbnNpZGVyZWQgaWYgYW55Ym9keSBo YXMgYSBiZXR0ZXIgaWRlYS48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlzdDpsMCBsZXZlbDEgbGZv MSI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGUgZHJhZnQgaXRz ZWxmIGhhcyBub3QgYmVlbiB1cGRhdGVkIHdpdGggdGhlIHBsYW5uZWQgY2hhbmdlcy4gSSB3aWxs IGdldCBiYWNrIHRvIGl0IGFzIHNvb24gYXMgSSBhbSBiYWNrIGZyb20gdmFjYXRpb24uPG86cD48 L286cD48L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPkhhcHB5IG5ldyB5ZWFyITxicj4NCkZyYW5jZXNjYTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4tLTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFm dC1pZXRmLWFjZS1wdWJzdWItcHJvZmlsZS0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRnJhbmNlc2NhIFBhbG9tYmlu aSBhbmQgcG9zdGVkIHRvIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SUVURiByZXBv c2l0b3J5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5OYW1lOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBkcmFmdC1pZXRmLWFjZS1wdWJzdWItcHJvZmlsZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+UmV2aXNpb246Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAwPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5UaXRsZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUHViLVN1YiBQcm9maWxlIGZv ciBBdXRoZW50aWNhdGlvbiBhbmQgQXV0aG9yaXphdGlvbiBmb3IgQ29uc3RyYWluZWQgRW52aXJv bm1lbnRzIChBQ0UpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Eb2N1bWVudCBkYXRlOiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyMDIwLTAxLTA0PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5Hcm91cDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgYWNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5QYWdlczombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMTk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5VUkw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1hY2UtcHVic3ViLXByb2Zp bGUtMDAudHh0Ij4NCmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1p ZXRmLWFjZS1wdWJzdWItcHJvZmlsZS0wMC50eHQ8L2E+IDxvOnA+DQo8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+U3RhdHVzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1hY2UtcHVic3ViLXByb2ZpbGUvIj5odHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLWFjZS1wdWJzdWItcHJvZmlsZS88L2E+DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPkh0bWxpemVkOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA8L3NwYW4+DQo8c3BhbiBsYW5nPSJTViIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1hY2UtcHVic3ViLXByb2ZpbGUtMDAiPjxzcGFuIGxhbmc9IkVOLUdCIj5odHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hY2UtcHVic3ViLXByb2ZpbGUtMDA8L3NwYW4+PC9h Pjwvc3Bhbj48c3BhbiBsYW5nPSJTViIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij4NCjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SHRtbGl6ZWQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0 bWwvZHJhZnQtaWV0Zi1hY2UtcHVic3ViLXByb2ZpbGUiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWFjZS1wdWJzdWItcHJvZmlsZTwvYT4gPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QWJzdHJhY3Q6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsgVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMg YW4gYXBwbGljYXRpb24gcHJvZmlsZSBmb3IgYXV0aGVudGljYXRpb248bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPiZuYnNwOyZuYnNwOyBhbmQgYXV0aG9yaXphdGlvbiBmb3IgcHVibGlzaGVy cyBhbmQgc3Vic2NyaWJlcnMgaW4gYSBwdWItc3ViIHNldHRpbmc8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPiZuYnNwOyZuYnNwOyBzY2VuYXJpbyBpbiBhIGNvbnN0cmFpbmVkIGVudmlyb25t ZW50LCB1c2luZyB0aGUgQUNFIGZyYW1ld29yay4mbmJzcDsgVGhpczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7IHByb2ZpbGUgcmVsaWVzIG9uIHRyYW5zcG9ydCBsYXll ciBvciBhcHBsaWNhdGlvbiBsYXllciBzZWN1cml0eSB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+Jm5ic3A7Jm5ic3A7IGF1dGhvcml6ZSB0aGUgcHVibGlzaGVyIHRvIHRoZSBicm9rZXIu Jm5ic3A7IE1vcmVvdmVyLCBpdCByZWxpZXMgb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PiZuYnNwOyZuYnNwOyBhcHBsaWNhdGlvbiBsYXllciBzZWN1cml0eSBmb3IgcHVibGlzaGVyLWJy b2tlciBhbmQgc3Vic2NyaWJlci1icm9rZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZu YnNwOyZuYnNwOyBjb21tdW5pY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m IHN1Ym1pc3Npb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPnVudGlsIHRoZSBodG1saXpl ZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PlRoZSBJRVRGIFNlY3JldGFyaWF0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5EYW5pZWwgTWlnYXVsdCAm bHQ7ZGFuaWVsLm1pZ2F1bHQ9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0K PGI+RGF0ZTogPC9iPk1vbmRheSwgMjMgRGVjZW1iZXIgMjAxOSBhdCAwMzoyOTxicj4NCjxiPlRv OiA8L2I+RnJhbmNlc2NhIFBhbG9tYmluaSAmbHQ7ZnJhbmNlc2NhLnBhbG9tYmluaUBlcmljc3Nv bi5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5EYW5pZWwgTWlnYXVsdCAmbHQ7ZGFuaWVsLm1pZ2F1 bHRAZXJpY3Nzb24uY29tJmd0OywgQWNlIFdnICZsdDthY2VAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+ U3ViamVjdDogPC9iPlJlOiBbQWNlXSBDYWxsIGZvciBhZG9wdGlvbiBkcmFmdC1wYWxvbWJpbmkt YWNlLWNvYXAtcHVic3ViLXByb2ZpbGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLCZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdSBhcmUgY29ycmVjdCwgdGhlIGNhbGwgaGFz IGV4cGlyZWQuIFBsZWFzZSB1cGxvYWQgdGhlIGRvY3VtZW50IGFzIGEgV0cgZG9jdW1lbnQhPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdXJz LCZuYnNwOzxicj4NCkRhbmllbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBTYXQsIERlYyAyMSwgMjAxOSBhdCAxMDoyOCBBTSBGcmFuY2Vz Y2EgUGFsb21iaW5pICZsdDtmcmFuY2VzY2EucGFsb21iaW5pPTxhIGhyZWY9Im1haWx0bzo0MGVy aWNzc29uLmNvbUBkbWFyYy4uaWV0Zi5vcmciPjQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3Jn PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGksPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5UaGlzIGFkb3B0aW9uIGNhbGwgaGFzIGVuZGVkIGEgd2hpbGUgYWdvLCBJIGFtIHdh aXRpbmcgZm9yIGEgY29uY2x1c2lvbiBiZWZvcmUgc3VibWl0dGluZyB0aGUgbmV4dCB2ZXJzaW9u IG9mIHRoZSBkb2N1bWVudCwgYWxzbyBpbiB2aWV3IG9mIG5leHQgaW50ZXJpbS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkhvcGUgeW91IGhhdmUgYSBoYXBweSBuZXcgeWVhciBjZWxlYnJh dGlvbiw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RnJhbmNlc2NhPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkFjZSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmFjZS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+YWNlLWJv dW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgRGFuaWVsIE1pZ2F1bHQgJmx0O2Rh bmllbC5taWdhdWx0PTxhIGhyZWY9Im1haWx0bzo0MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPjQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDs8 YnI+DQo8Yj5EYXRlOiA8L2I+VHVlc2RheSwgMTkgTm92ZW1iZXIgMjAxOSBhdCAwOTo0NTxicj4N CjxiPlRvOiA8L2I+QWNlIFdnICZsdDs8YSBocmVmPSJtYWlsdG86YWNlQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+YWNlQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W0Fj ZV0gQ2FsbCBmb3IgYWRvcHRpb24gZHJhZnQtcGFsb21iaW5pLWFjZS1jb2FwLXB1YnN1Yi1wcm9m aWxlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5EZWFyIHdvcmtpbmcgZ3JvdXAsJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BcyBt ZW50aW9uZWQgZHVyaW5nIHRoZSBBQ0UgbWVldGluZywgdGhpcyBtYWlsIHN0YXJ0cyBhIGNhbGwg Zm9yIGFkb3B0aW9uIGZvciBkPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5yYWZ0LXBhbG9tYmlu aS1hY2UtY29hcC1wdWJzdWItcHJvZmlsZS4gUGxlYXNlIHByb3ZpZGUgeW91ciBmZWVkIGJhY2tz IGJ5DQogRGVjZW1iZXIgNC4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdp bi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wYWxvbWJpbmktYWNlLWNvYXAt cHVic3ViLXByb2ZpbGUvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtcGFsb21iaW5pLWFjZS1jb2FwLXB1YnN1Yi1wcm9maWxlLzwvYT48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPllvdXJzLA0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPkRhbmllbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90 dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpBY2UgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOkFjZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPkFjZUBpZXRmLm9y ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2FjZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vYWNlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D840FBD06CEE449BAD2CF37BB96D6D38ericssoncom_-- From nobody Mon Jan 6 02:03:02 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D624120127; Mon, 6 Jan 2020 02:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M95b47-vbvQI; Mon, 6 Jan 2020 02:02:58 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C349120124; Mon, 6 Jan 2020 02:02:58 -0800 (PST) Received: from wangari.tzi.org (p54BDE7FE.dip0.t-ipconnect.de [84.189.231.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 47rrfm0jbNzyNT; Mon, 6 Jan 2020 11:02:56 +0100 (CET) From: Olaf Bergmann To: Jim Schaad Cc: "'Benjamin Kaduk'" , , References: <20200102234020.GI35479@kduck.mit.edu> <014601d5c2b8$9947acc0$cbd70640$@augustcellars.com> Date: Mon, 06 Jan 2020 11:02:55 +0100 In-Reply-To: <014601d5c2b8$9947acc0$cbd70640$@augustcellars.com> (Jim Schaad's message of "Fri, 3 Jan 2020 20:36:54 -0800") Message-ID: <878smkrjg0.fsf@wangari> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 10:03:00 -0000 Jim, Jim Schaad writes: [Ben's review] > We also are potentially in violation of the framework's requirements with= respect to the independent selection of profiles for client/AS and client/= RS interactions -- at present, when DTLS+RPK is used for client/RS, we requ= ire that DTLS+RPK is also used for client/AS, in order to prove possession = of the key. We could perhaps weasel our way out by saying that the framewo= rk's requirement applies at the profile granularity, and with symmetric PSK= we can be fully independent, but we still need to say something about this= property and the interaction with the framework's requirements. > > [JLS] I am missing where it is saying this. Can you give a pointer? I = don't believe that the POP of the RPK is required at the time that the toke= n is obtained. The problem is that AS must bind the Access Token to the RPK that the Client has presented, and the Client must use the very same RPK to establish the DTLS channel with RS. Otherwise, RS cannot be sure that AS has issued the Token to the same entity that is currently communicating with RS. Gr=C3=BC=C3=9Fe Olaf From nobody Mon Jan 6 09:20:58 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 76BAB1208C3; Mon, 6 Jan 2020 09:20:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov via Datatracker To: "The IESG" Cc: draft-ietf-ace-coap-est@ietf.org, Jim Schaad , ace-chairs@ietf.org, ietf@augustcellars.com, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alexey Melnikov Message-ID: <157833125548.8096.5084396209808710109.idtracker@ietfa.amsl.com> Date: Mon, 06 Jan 2020 09:20:55 -0800 Archived-At: Subject: [Ace] Alexey Melnikov's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 17:20:56 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-ace-coap-est-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for this well written document. And thank you for addressing my points in github. A remaining comment (which might or might not have been resolved): 5.1. Discovery and URIs Clients and servers MUST support the short resource EST-coaps URIs. Just to clarify: the original EST URIs are prohibited in COAP-EST? From nobody Mon Jan 6 09:30:34 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E73C120872; Mon, 6 Jan 2020 09:30:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=oSyWz6jv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=xDheIDs1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTYh26isBjUb; Mon, 6 Jan 2020 09:30:25 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A75C12086C; Mon, 6 Jan 2020 09:30:25 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 35E5E21D2B; Mon, 6 Jan 2020 12:30:24 -0500 (EST) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Mon, 06 Jan 2020 12:30:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=9UFv/0OMCP+yvFxa8C8tbYEufGYVV3G EhJBzbc9ZO1I=; b=oSyWz6jv6T6TuSvyJsTXSlk7hZTuOdCvbG9DXOhkk3yt487 J7PYeBLj6bcrzTcXyH5WzBoUDCNDZlG7qnpzN/PnXb8inA0NKqA+VBdOZbQi58cb miC17PheRe0iV4xAoOtG2QuiGwEkVWO7MngvFHRLmCUE8lgPl7rnK8BiAlkbThQZ 7LGM01wRdvMmS8YBg2lxEH4CIfRbdniHpTQ75mgWjtp3LAWtKpYUPfUYpFEIBDC3 7cbk1wg2he3yekBwSCoY53lncaoZBKK4J0IrU5XDs1YNdLKe0FTKULL8ahrhStAx 5Wr36Wjr1QRxMCLL4RXrhBEqjvBZlPifYa6sD2g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=9UFv/0 OMCP+yvFxa8C8tbYEufGYVV3GEhJBzbc9ZO1I=; b=xDheIDs1UoyQu3pHcum1Sk r2+NxENw+SLaSFXdj2F+7p3KNsyuCjC1cvkvHFU/ZyliJh+BBdjtK4lqiF92YqDF YCcE4C8R/senilbrXm6Jha5MGOEwJ7159CUVQI6B/HKEoQb0WzKedGnjHzLfx7/f X8dz7IxiIoW9kDQLwgcJywgI1gK7MSEqTAXYyBZRbtmCQafxCDGsr6ARryZc3kIC uLeHiwbF+RKi/OMAldpCbrcaKr/cP2/BPWuH2vV2zB+I/7wVQD9V0yq7V4vALJTp RRC2rMcJZiOuv4G6cjVRoDXFdo6yENNV8/H07DvoEFkUdo6wvcu/eu957Lmy72Fg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdehtddguddtvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedftehl vgigvgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilh drfhhmqeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecurfgrrhgrmhepmhgrihhl fhhrohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmhenucevlhhushhtvg hrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B608BC200A4; Mon, 6 Jan 2020 12:30:23 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-731-g1812a7f-fmstable-20200106v2 Mime-Version: 1.0 Message-Id: <49f1a8ec-3b10-4af0-88c5-ddc097b8353a@www.fastmail.com> In-Reply-To: References: <157667562611.29907.6804425237641037015.idtracker@ietfa.amsl.com> <20191220004728.GF35479@kduck.mit.edu> <12E7D8E7-8354-4700-B92E-A07A9BC4B881@tzi.org> <32540abd39940ad245e3c814e64a40e7@bbhmail.nl> Date: Mon, 06 Jan 2020 17:30:02 +0000 From: "Alexey Melnikov" To: "Panos Kampanakis" Cc: "ace-chairs@ietf.org" , "Jim Schaad" , "Ace Wg" , "The IESG" , "draft-ietf-ace-coap-est@ietf.org" Content-Type: multipart/alternative; boundary=b8a941071a554ab593a83a1ea2aff90f Archived-At: Subject: Re: [Ace] =?utf-8?q?Alexey_Melnikov=27s_Discuss_on_draft-ietf-ace-co?= =?utf-8?q?ap-est-17=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 17:30:27 -0000 --b8a941071a554ab593a83a1ea2aff90f Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Panos, On Fri, Dec 27, 2019, at 5:20 AM, Panos Kampanakis (pkampana) wrote: > Hi Alexey, >=20 > This commit https://github.com/SanKumar2015/EST-coaps/commit/77d65f0eb= 7a28282f363e5e48cd0d28970f9366e should address your feedback. The full d= iscussion is in https://github.com/SanKumar2015/EST-coaps/issues/155 >=20 > Let us know if it does not make sense. Yes, the changes look fine to me. I just cleared my DISCUSS. Best Regards, Alexey > Rgs, > Panos >=20 > *From:* Ace *On Behalf Of *Alexey Melnikov > *Sent:* Monday, December 23, 2019 9:42 AM > *To:* consultancy@vanderstok.org; Carsten Bormann > *Cc:* ace-chairs@ietf.org; Jim Schaad ; Benjam= in Kaduk ; Ace Wg ; The IESG ; draft-ietf-ace-coap-est@ietf.org; Klaus Hartke > *Subject:* Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-= est-17: (with DISCUSS and COMMENT) >=20 > Hi Peter, >=20 > On Mon, Dec 23, 2019, at 9:12 AM, Peter van der Stok wrote: >> HI all, >>=20 >> We had this discussion about this specific text several times. >> I like to keep at least some text for the following reason: >> Implementers, new to coap without a photographic memory of RFC7252 te= xt, are surprised by the absence of uri host in the examples, and tend t= o assume an error. >>=20 >> The curent text does not look like a "normative rephrasing" to me. >> Nevertheless, is the suggestion below acceptable to everyone? >>=20 >> OLD >>=20 >> The Uri-Host and Uri-Port Options can be omitted if they coincide >> with the transport protocol destination address and port >> respectively. Explicit Uri-Host and Uri-Port Options are typically >> used when an endpoint hosts multiple virtual servers and uses the >> Options to route the requests accordingly. >>=20 >> NEW >> Section 5.10.1 of RFC7252 specifies that the Uri-Host and Uri-Port Op= tions can be omitted if they coincide >> with the transport protocol destination address and port >> respectively.=20 >>=20 >> Other suggestions are welcome. > Your suggested text is much better. >=20 > Thank you, > Alexey >> Peter >> Carsten Bormann schreef op 2019-12-20 18:16: >>> On Dec 20, 2019, at 17:34, Klaus Hartke wrot= e: >>>>=20 >>>> I would prefer if draft-ietf-ace-coap-est didn't say anything here,= >>>> since the Uri-Host and Uri-Port options and whether they should be >>>> omitted or not is entirely specified by CoAP [RFC7252].* >>>=20 >>> Klaus has an important point here. >>>=20 >>> We need to be **much more** vigilant about specifications messing wi= th their normative references. >>> Saying how they are used, yes, but re-stating (or, worse, re-interpr= eting) normative material from those references is prone to creating dia= lects that no longer interoperate with their unadulterated originals. Un= less these are hopelessly broken(*) and this is the only way to fix them= , this is a MUST NOT. >>>=20 >>> Gr=C3=BC=C3=9Fe, Carsten >>>=20 >>> (*) the normative reference EST has an example for that case: The us= e of content-transfer-encoding with HTTP, which is explicitly ruled out = in Section 19.4.5 of RFC 2616 (and now appendix A.5 of RFC 7231). That w= as a count of RFC 7030 messing with a normative reference, and in turn *= *needed** to be messed with in CoAP-EST (and eventually needs to be fixe= d in the parent specification, too). >=20 >=20 > *Attachments:* > * smime.p7s --b8a941071a554ab593a83a1ea2aff90f Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Panos,<= br>

On Fri, Dec 27, 2019, at 5:20 AM, Panos Kam= panakis (pkampana) wrote:
<= div class=3D"qt-WordSection1">

Hi Alexey,

 

This commit https://github.com/SanKumar2015/EST-coaps/commit/77d65f0eb7a28282f36= 3e5e48cd0d28970f9366e should address your feedback. The full discuss= ion is in https://github.com/SanKumar2015/EST-coaps/issues/155

 

Let us know if it does not mak= e sense.

Yes, the changes look fin= e to me. I just cleared my DISCUSS.

Best Re= gards,
Alexey
 

Rgs,

Panos

 

From: Ace <ace-bounces@ietf.org> On Behalf Of Alexey Melnikov<= br>
Sent: Monday, December 23, 2019 9:42 AM
To: consultancy@vanderstok.org; Carsten Bormann <cabo@tzi.o= rg>
Cc: ace-chairs@ietf.org; Jim Schaad <ietf= @augustcellars.com>; Benjamin Kaduk <kaduk@mit.edu>; Ace Wg <= ;ace@ietf.org>; The IESG <iesg@ietf.org>; draft-ietf-ace-coap-e= st@ietf.org; Klaus Hartke <hartke@projectcool.de>
Subject: Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap= -est-17: (with DISCUSS and COMMENT)

 

Hi Peter,=

 

On Mon, Dec 23, 2019, at 9:12 AM, Peter van der = Stok wrote:

HI all,

 

We had this discussion about this specific text several time= s.

I like to keep at least s= ome text for the following reason:

Implementers, new to coap without a photographic memory of RFC725= 2 text, are surprised by the absence of uri host in the examples, and te= nd to assume an error.

 = ;

The curent text does not l= ook like a "normative rephrasing" to me.

Nevertheless, is the suggestion below acceptable to everyon= e?

 

=

OLD

 

The Uri-Host and Ur= i-Port Options can be omitted if they coincide

   with the transport protocol destination = address and port

  = ; respectively.  Explicit Uri-Host and Uri-Port Options are typical= ly

   used when an= endpoint hosts multiple virtual servers and uses the

=

   Options to route the requests acc= ordingly.

 

NEW

Section 5.10.1 of RFC7252 specifies that the Uri-Host and Uri-P= ort Options can be omitted if they coincide

   with the transport protocol destination addr= ess and port

   re= spectively. 

 
=

Other suggestions are welcome.<= br>

Your suggested = text is much better.

 <= br>

Thank you,

Alexey

Peter

Carsten Bormann schree= f op 2019-12-20 18:16:

On Dec 20= , 2019, at 17:34, Klaus Hartke <hartke@projectcool.de> wrote:

 

I = would prefer if draft-ietf-ace-coap-est didn't say anything here,=

since the Uri-Host and Uri-Port = options and whether they should be

omitted or not is entirely specified by CoAP [RFC7252].*

 

=

Klaus has an important point here.

 

We need to be **much more** vigilant about specifi= cations messing with their normative references.

Saying how they are used, yes, but re-stating (or= , worse, re-interpreting) normative material from those references is pr= one to creating dialects that no longer interoperate with their unadulte= rated originals.  Unless these are hopelessly broken(*) and this is= the only way to fix them, this is a MUST NOT.

=

 

Gr=C3=BC=C3=9Fe, Carsten

 

(*) the normative r= eference EST has an example for that case: The use of content-transfer-e= ncoding with HTTP, which is explicitly ruled out in Section 19.4.5 of RF= C 2616 (and now appendix A.5 of RFC 7231).  That was a count of RFC= 7030 messing with a normative reference, and in turn **needed** to be m= essed with in CoAP-EST (and eventually needs to be fixed in the parent s= pecification, too).

=

 


=
Attachments:
  • smime.p7s

--b8a941071a554ab593a83a1ea2aff90f-- From nobody Mon Jan 6 09:32:40 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC8F12091F; Mon, 6 Jan 2020 09:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ZW/kmL6D; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=Uj+KYdFU Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxmGgAeKbJBU; Mon, 6 Jan 2020 09:32:30 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56FDD12092E; Mon, 6 Jan 2020 09:32:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7946; q=dns/txt; s=iport; t=1578331926; x=1579541526; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4OvQgD0+9YfJTDZOHxx5A//oasqcms2Y5oNR1fNaCX8=; b=ZW/kmL6DCHjpMxBtwduImOfom0P7F1wsJW6u+nzCNTh3f0E3nksjvirB xpJGefhraLFyTtgp7L4YU0afOB+M2nweZp1jiUH0FChaYlMojqHIcU9Cp DOpnlz7so1PxJeOquUdWsI+SEBejx1+YK3Nz4t/8khKakWzezL2c85Xrd I=; X-Files: smime.p7s : 4024 IronPort-PHdr: =?us-ascii?q?9a23=3Ao4uu4h2zr1B+egSKsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQEU7yKebjaSUSF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYBQD0bRNe/49dJa1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXyBVFAFbCstIAQLKodPA4sAgl+YDYFCgRADVAIHAQEBCQMBARg?= =?us-ascii?q?LCgIBAYRAAoFpJDgTAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQECAQEBEC4BASw?= =?us-ascii?q?LAQQHBAIBCA4DBAEBLwIlCx0IAgQBDQUIBhSDAYF5TQMOEQ8BAgyiRQKBOIh?= =?us-ascii?q?hgieCfgEBBYFJQYJ4GIIFBwMGgTaBU4pGGoFBP4ERR4JMPoJkAQEBAgGBLAE?= =?us-ascii?q?SAQkYFYMrgiyNTYlNmAMKgjaDYYI4gRuPAYJGh32QGI5TiFOSBgIEAgQFAg4?= =?us-ascii?q?BAQWBaSJnWBEIcBU7gmxQGA2NEgwXFYM7hRSFP3QBgSeLDYIyAQE?= X-IronPort-AV: E=Sophos;i="5.69,403,1571702400"; d="p7s'?scan'208";a="405578797" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Jan 2020 17:32:05 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 006HW4rV024531 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 6 Jan 2020 17:32:05 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 6 Jan 2020 11:32:03 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 6 Jan 2020 12:32:03 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 6 Jan 2020 12:32:03 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UjOeTbtbKrG3Fh4zpoGwU5Otou+BC6NXSy5lwSq3XBcByxj5E216DtDkvcQWdNPrmdIDWQD67vuIVo8DBgtcB7oodeiExdUbXLX9YtMbC/FahW+t/coiGE3QudwJhROUsxp4T1aDiRULAl7A7pBqljf4cXDev8xErZr8hvUXSGisBXhdRD3vO0zDc6h1k+rzEPVhhOBeVIT95TgnYtPGzrHexPoUiXIC0M1AtjIxsTosfnBviZReutNnNodZ6h48yVWZG58yDZj5EZ/6Uiox0uiX9mfktbxF7ETdUPdJvzAw1ID2/p13RQXTi5T/hUv4s9bVet6ZO2huaZBVRa8JfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YZJ7xoGY9XdVMk22fJCraCeCh/ryvhsB7XVmiLyspvA=; b=aVqPzBltikGh+XrDeuo0vtoAtHE/SIEGxrbYjNv7Cu+7CraT+PbrQBQZjdCYh3SeV/D2c3fzpTrMBemcMssedOlPxdpt9voKR08SpuLevouivLsqjDk10OrFuNF+RKJqT49WW7xtCOPp/gYe5bBkhlCETdOIMnoymJ4MEloqKapg6oX3xCcQ04ThyZVuf6HAjwAMiJ60JM7PtR1Wol512g5lBtDM/7e3V6jF3yXeH7D03tFcziCdTbd77iej/y8Egsjw7dN/7m7C68eXwwH2eT0MMFoypOEXYhYtdFQUqgMSzYIEuKzbwK2k2VZki+DEFl6wcTQpcELFFzVg7HMoag== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YZJ7xoGY9XdVMk22fJCraCeCh/ryvhsB7XVmiLyspvA=; b=Uj+KYdFUw6CuVuxM8AAMQez6Msi0DOT6zjZCpiuEOjZHjbSlgdk3n9UTv8GorwUlP7NQtgeAU2iaMMN/Ggrd91DDBCfLLkOuLUesROSPlGY2koTI4kdQ6d4JFHtss5xfnjs/Fr1Gt+zR18qqGzapBB5TWZ5ZQmRrCYY1bilJEMs= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2689.namprd11.prod.outlook.com (52.135.245.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.11; Mon, 6 Jan 2020 17:32:02 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f%7]) with mapi id 15.20.2602.016; Mon, 6 Jan 2020 17:32:02 +0000 From: "Panos Kampanakis (pkampana)" To: Alexey Melnikov , The IESG CC: "draft-ietf-ace-coap-est@ietf.org" , "ietf@augustcellars.com" , "ace-chairs@ietf.org" , "ace@ietf.org" Thread-Topic: [Ace] Alexey Melnikov's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT) Thread-Index: AQHVxLW3X1uUsmpunkObZgfv+Q4LKqfd4ksw Date: Mon, 6 Jan 2020 17:32:02 +0000 Message-ID: References: <157833125548.8096.5084396209808710109.idtracker@ietfa.amsl.com> In-Reply-To: <157833125548.8096.5084396209808710109.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1001::1da] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: da18d161-7929-460e-ee35-08d792ce5778 x-ms-traffictypediagnostic: BN7PR11MB2689: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0274272F87 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(366004)(346002)(136003)(39860400002)(13464003)(189003)(199004)(8936002)(2906002)(71200400001)(7696005)(54906003)(53546011)(6506007)(316002)(110136005)(81166006)(5660300002)(52536014)(81156014)(186003)(86362001)(8676002)(33656002)(66476007)(66616009)(66946007)(966005)(4326008)(66556008)(9686003)(76116006)(64756008)(66446008)(55016002)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2689; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: tu1mg142MVUVkKI7v6n1jpVNUhpxONq1ufso20uUDOfIiX61H7hBo9s2w3bvdW0f+QkBQU2uH9Qa34MXlhqEFIL3AB7+CYRfzV2VVNrwRtTwViGgNx/MFTsOz8NKbB4hRqNLQe65WTDqFfMOYqGhdCzwVJHzLRFnhB29BwsupfLyplMzsqnLEx1FuZJrutoNQhNr/QmW/BDI1mf351ogXHWgriSjvQgCtUihOxJhguzn6vQ8cW7jqm5mRzLiEN0LdQPEqNXJOhPxkWVatGXSQhC/DhadDbBFW46zVjBBNeSORb4FcLyOachkX1m9XnNEHtNav0LZ5XB3VIwq3+kRUDN5aRrgHUCt3E26p1lci78YHbnC7kPCSY9GOjWHuQdknP6dir/a7+g+r2TkIRY+SpwWQNy/5Dt2+9P1p8sj3RA17kVEHcSR5vPEYQ/ijHxU0R3G+HuyYpW84swkUh/h/uolXtCMqJQRcLs+0vHN/alK5xAkodW+ewq2XPQnK1WndR6NvaivREpESOCWiakvqA== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0013_01D5C48D.4B7417F0" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: da18d161-7929-460e-ee35-08d792ce5778 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2020 17:32:02.3526 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: lbHNQL5TeWdspNBqFwTwZKj93oWyhe4GNEd8bj4cm3WvUE4vnqORutHlLuBlACkqfzsif+fopx3Sd2LLQgkp8A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2689 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.18, xch-rcd-008.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [Ace] Alexey Melnikov's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 17:32:34 -0000 ------=_NextPart_000_0013_01D5C48D.4B7417F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Alexey, > Just to clarify: the original EST URIs are prohibited in COAP-EST? No we don't forbid them in the draft. We do not make them MTI either though. The long URIs can be supported and they would be a non-default EST-coaps resource that a server could support and a client could do resource discovery for. So we did not add text to say "MUST NOT implement the long URIs". The mandatory to implement/support EST-coaps URIs are the short URIs for EST-coaps though. Panos -----Original Message----- From: Ace On Behalf Of Alexey Melnikov via Datatracker Sent: Monday, January 06, 2020 12:21 PM To: The IESG Cc: draft-ietf-ace-coap-est@ietf.org; ietf@augustcellars.com; ace-chairs@ietf.org; ace@ietf.org Subject: [Ace] Alexey Melnikov's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT) Alexey Melnikov has entered the following ballot position for draft-ietf-ace-coap-est-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for this well written document. And thank you for addressing my points in github. A remaining comment (which might or might not have been resolved): 5.1. Discovery and URIs Clients and servers MUST support the short resource EST-coaps URIs. Just to clarify: the original EST URIs are prohibited in COAP-EST? _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace ------=_NextPart_000_0013_01D5C48D.4B7417F0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDGkw ggNDMIICK6ADAgECAhBf+HsoK1TcjUKjFbVoya3/MA0GCSqGSIb3DQEBBQUAMDUxFjAUBgNVBAoT DUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNpc2NvIFJvb3QgQ0EgMjA0ODAeFw0wNDA1MTQyMDE3 MTJaFw0yOTA1MTQyMDI1NDJaMDUxFjAUBgNVBAoTDUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNp c2NvIFJvb3QgQ0EgMjA0ODCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBALCauaunrwp3 p+JxtrRmYpR4iEfGYlWEQDK/wKsupRxx1rxue6iqum7SFYhIRZ2i/IPQzLmM4CZocEp43yEXnvRh BckVyM8W2jVhiZRDqISoMZh4m7lObyxTEmzNHa0rJLsxxCv/g0Rvtj0kdwnqvyqoH2pW9iAPEVSX gXWnJc5ZaoJl77fq5+KNdYtu8t1Ppl5inM8QCmTQTm3OK8xb9WClJ0eNafR/zhtw3nAbINZuzaYB qDwS0qk/oGteu44gi3qR47Vo7qDnxAF0qFMLK0qaD2USDoJNjmP97+ubGttTphNgr8J918dsFyXU c/tHZFCBgJRM4b+uSxzfku0uBd8CAQOjUTBPMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/ MB0GA1UdDgQWBBQn88gVHm6aAgkWrSugiWBf2nsvqjAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG 9w0BAQUFAAOCAQEAnZ2EhKNBqXx3DLdTyk5EUGLvVHzTdRcc6ODGSEu2/kw6GYFWsFbuGZZiqlqj ZMH2TlQzxnf+xRy65V0lyvXwk5qDES7my/h0Rf7nBbir59/LS+E3hNq5i5dwHvDii9ew2A6dsWnW KpF7qUlPfuaOldiDJzzVaEkO1J32LuunvuswpKwfRPyVqzMG+31gCt60imOwnKnypLlTAYfQaKQn f6v/6frJQDiIZ7Q5xoRvV8lT27qO7sBDsvgJg27/Zs8+7xezWBglCTRe48vWFLbs8pJvdOQvgSrV kpHg4Jc8MmgFhUvR91fiUh2TGlSfBXDASnFgHkMLYB7+o86BGeELNTCCBG4wggNWoAMCAQICCmEQ gG0AAAAAAA4wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UE AxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTE0MDQwNDIwMjQxOFoXDTI5MDUxNDIwMjU0MlowLDEO MAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVlIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyt9+FkxTFfsjVs3GuWUKBJXl3kxFZ4wMxwbgqx9tXzcqe+fto62A fxHI84Lr7p9Q2cm/PaEvuzwRBzXvuKXZUU7ZsPdToJSALCySZa0Qb6GGa19ACpmlUEQakE3P5kz7 RgaNSOMH1+GtY9fV6CcAFb9uB7JDu2UGL332WV2bEsUsfb3rRLBS4cL8Hu2dWfcdk6erMaZCQjkn 04FixlQsJozbPRTQqI4V6iikG/69rDyeTdbVTK+My/9LnwVsD3GBMiRh7RmrvupxtGiMu8j05Is/ d1OifhWecwvjV3Reg9Lok8bMNJEMAped1weTdVS0X4MsAheosJBld9lS5O4idwIDAQABo4IBhzCC AYMwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFJ+VNrSOXdVLwwrBpymTQ1EG/YlRMBkGCSsG AQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB8G A1UdIwQYMBaAFCfzyBUebpoCCRatK6CJYF/aey+qMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly93 d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jcmwvY3JjYTIwNDguY3JsMFAGCCsGAQUFBwEBBEQw QjBABggrBgEFBQcwAoY0aHR0cDovL3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL2NlcnRzL2Ny Y2EyMDQ4LmNlcjBcBgNVHSAEVTBTMFEGCisGAQQBCRUBFQAwQzBBBggrBgEFBQcCARY1aHR0cDov L3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL3BvbGljaWVzL2luZGV4Lmh0bWwwDQYJKoZIhvcN AQEFBQADggEBAD5OviMaRgKNXmvbigI0C2Ob5QE8Jl2McLIk62Be7IqEZC4bWRWjZxrhFuP94E19 RJojKNLttveiH+dEze1t6oYhVCisbGG8+8hlUARAiiqL/J9uGJ71xT6loqkcAK5xphe7STJLSlgT k0w26fcvDeiA6zhdVHnKhVKkpOJWd9MNByFOnCQyDOK+pcNxLU6IN9TwL1ZoRkdFa11QiCX3Oimk 8YhBrVN+VzGGKtbgZ4fYU6uBo3V3vtshyDpHtGkn1e7f9/TWcY26etFzL33dzaZ4lChlw4l3XkLq 6AfCEDF5djpBdiCRjwpBUIIbCSmyESBvA+sL4j8i1vo/uEartrAwggSsMIIDlKADAgECAgoBhhEi QTzquitVMA0GCSqGSIb3DQEBCwUAMCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBF bXBsb3llZSBDQTAeFw0xOTEyMjAxOTQ5MDJaFw0yMTEyMTkxOTU5MDJaMIGfMSQwIgYDVQQDExtQ YW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkxFDASBgNVBAsTC0Npc2NvIFVzZXJzMRIwEAYDVQQL EwlFbXBsb3llZXMxEzARBgoJkiaJk/IsZAEZEwNjb20xFTATBgoJkiaJk/IsZAEZEwVjaXNjbzEh MB8GCSqGSIb3DQEJAQwScGthbXBhbmFAY2lzY28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAmIHTLIzoAnuMUiHMx8V+PF9JpAcB7zrNHOY1Vj1R1Vx7ty7m9yo9G991T2n7zHo4 UzF6tnB9NxzQOKCY54oqP5KjVGYOPPo+qZ+2rx1GABzdKUF4LwUUKOTf9uXAtvsvIRUc5J/csShT jcUIvtVmiAzWXWRfMYShjBYBVtx/h8fDqAqfFAzd6HG0TcdsN/BRb9k6QEW1afHjPKlRUaDRELyj nFGJZd2OsUJ7/aKMdFmQFd2CAJYzsuwLYjeqJsuGNzBc/k6mzQPf6FW17nz17G41KReU0UdZf2yZ jvimkwCQ/yW8SVTOcGBP+Zk+Lq5EYEGQMu1qtNK/97bXMc5kuwIDAQABo4IBWjCCAVYwDgYDVR0P AQH/BAQDAgTwMAwGA1UdEwEB/wQCMAAwegYIKwYBBQUHAQEEbjBsMDwGCCsGAQUFBzAChjBodHRw Oi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY2VjYS5jZXIwLAYIKwYBBQUHMAGG IGh0dHA6Ly9wa2ljdnMuY2lzY28uY29tL3BraS9vY3NwMB8GA1UdIwQYMBaAFJ+VNrSOXdVLwwrB pymTQ1EG/YlRMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jaXNjb2NlcnRzLmNpc2NvLmNvbS9m aWxlL2NlY2EuY3JsMB0GA1UdEQQWMBSBEnBrYW1wYW5hQGNpc2NvLmNvbTAdBgNVHQ4EFgQUjrl7 6Mrrdw3ZYFiTpZBdtrUm5P4wHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZI hvcNAQELBQADggEBAMhR6xCTygu68lppjWebXTXYznix5961hcmwiJRkPtUIGQ5JQwXyCwq/Juuq yc5ebeq9cQEO5iqyxik/UAQ35BlmKb7SNLi75RtFE/AIZrRsEjTUoO2EtCMQOEMcenWa2XE8fEID BkwzreKeaOchCbDd4L9PvKFht6nDDFtb6VZdWs4ort+J3iFeilVf3oI5MSVi+qroWaFLnLYTQGTn qEjWANfKw3RRBAMdoPCZ+N4eftAk1TWVS08nOsPoKWXtIqX6y0ZPs/EZjBSk57v1TPLpYhEqYGXI oGJlIvzIAfYNoUg8yP8toG5T7x+7hRz0MMUGWcCDsS9PMFxH6SnrUSMxggMNMIIDCQIBATA6MCwx DjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTAN BglghkgBZQMEAgEFAKCCAaQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMjAwMTA2MTczMjAxWjAvBgkqhkiG9w0BCQQxIgQg4dBJczYN01QZZQr7oNPxKN9NVPbehjKE hdxOka4oeGwwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lz Y28gRW1wbG95ZWUgQ0ECCgGGESJBPOq6K1UwSwYLKoZIhvcNAQkQAgsxPKA6MCwxDjAMBgNVBAoT BUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTCBoAYJKoZIhvcN AQkPMYGSMIGPMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDALBglghkgBZQMEAgEwCwYJKoZIhvcN AQEKMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEA IjKDJWTn3oqux3pxNKwsALntBxn9UQIB0hEeiLwlxucKkSvVCP4Z7Qx2ElTP71FpOZMvX/UXBz4y yau6CH315H3KoGJ1UcaIW8w/vNzAgvA2uMts8GjuA5fNYYna0+LOznggP07fbIBjL6dZalFGOjjS zk1qPFiekE1Z/g8vT8ZCPp67ufBHvFM2qTBzl2NPA0ItZNVkqAlou2JQNJm5ka2UErOI+ORLMBUF CA4enDDwzYmPvwPFLxvQ07GYhdiXs0z8+i4KX6gxPQsgAztBTb7wOhJhTLXVelXswe5u1eumRsq/ l/NkzKykbAg0HwMmbwwWEq6Uw5KUTOW+zR/oZQAAAAAAAA== ------=_NextPart_000_0013_01D5C48D.4B7417F0-- From nobody Mon Jan 6 09:38:10 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAAD1120872; Mon, 6 Jan 2020 09:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=hmn2z1Zr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FboivIr3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTcA7zZM_DpQ; Mon, 6 Jan 2020 09:38:00 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CF201200FB; Mon, 6 Jan 2020 09:38:00 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 9DA3A22040; Mon, 6 Jan 2020 12:37:59 -0500 (EST) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Mon, 06 Jan 2020 12:37:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=8sLctPq7V5mpEUbbBRtb/+oOC7RUgaO 15SaKXmVp9i8=; b=hmn2z1ZrIahzIY8ZI49+jfSAHaQEOJg9bxQYzGHuRg1Z1Kf 3q0uZb+L81ga6csS1SYx3uu2NOerILQSGvLlTimh8YE1lHU7caxafZnjC7sA3Pni QJCh7plfxovYIPEjUGH31q+vqIXwIKsi7w9WP/nEEJTkueLvXR4rNgE467+gFdj+ 05tGia0NLamm2iF3QlV6oAYgGDTqdAW5QT4sdHKXMSDZQRYxC/JHWkbwZ+1XQ3tX aXuDoWjZGfIgCV88aQcVgwjsKQZWycpiuDp8Vs40sXM9LKKtyPXzSB/LYU3cKp8o 3lwdghnQFvp1agzxE1BvIemTuVVtUpRDKX8tNCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=8sLctP q7V5mpEUbbBRtb/+oOC7RUgaO15SaKXmVp9i8=; b=FboivIr3oSrS/DHlG6bmN6 h5r2ZeutPSzEWlqn4dpN5sKqSOBM3tChBZxhaUmD733BoLlcew3i2shBljmhjU8O 7VgvQh5v6G+mLoeo2wTum4hX+NQtsCSgKhRo4uSvg1WrWGt4G0j1N/6nV5cffqxV LTeSpCsAh8iSerJZcczaYxuzT23hS6okYO/wnEaac4j9Huw7uu1HAcfTUgCaqhLC SZZ4YuihqzPZr2HLFgLhaBY1862TqsfJHy5mfrUaOH4kdTyWunYuOVHSJuH8WVgp OikM+7vs6v5W3kkH/mnK8uOFL1qhYRANQdrcY4BeehwEYT6ViL68Xba1cSTmUbsw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdehtddguddtgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsehttdertderreejnecuhfhrohhmpedftehl vgigvgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilh drfhhmqeenucffohhmrghinhepihgvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhr ohhmpegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmhenucevlhhushhtvghruf hiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 78940C200A4; Mon, 6 Jan 2020 12:37:59 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-731-g1812a7f-fmstable-20200106v2 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <157833125548.8096.5084396209808710109.idtracker@ietfa.amsl.com> Date: Mon, 06 Jan 2020 17:37:38 +0000 From: "Alexey Melnikov" To: "Panos Kampanakis" , "The IESG" Cc: "draft-ietf-ace-coap-est@ietf.org" , "Jim Schaad" , "ace-chairs@ietf.org" , "ace@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [Ace] =?utf-8?q?Alexey_Melnikov=27s_No_Objection_on_draft-ietf-a?= =?utf-8?q?ce-coap-est-17=3A_=28with_COMMENT=29?= X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 17:38:03 -0000 Hi Panos, On Mon, Jan 6, 2020, at 5:32 PM, Panos Kampanakis (pkampana) wrote: > Hi Alexey, > > > Just to clarify: the original EST URIs are prohibited in COAP-EST? > > No we don't forbid them in the draft. We do not make them MTI either though. > The long URIs can be supported and they would be a non-default EST-coaps > resource that a server could support and a client could do resource > discovery for. So we did not add text to say "MUST NOT implement the long > URIs". The mandatory to implement/support EST-coaps URIs are the short URIs > for EST-coaps though. After the followup discussion, I was thinking more about adding something along the lines of "MAY implement the long URIs". But this comment is non blocking and I am sure you will do the right thing. Best Regards, Alexey > Panos > > > -----Original Message----- > From: Ace On Behalf Of Alexey Melnikov via > Datatracker > Sent: Monday, January 06, 2020 12:21 PM > To: The IESG > Cc: draft-ietf-ace-coap-est@ietf.org; ietf@augustcellars.com; > ace-chairs@ietf.org; ace@ietf.org > Subject: [Ace] Alexey Melnikov's No Objection on draft-ietf-ace-coap-est-17: > (with COMMENT) > > Alexey Melnikov has entered the following ballot position for > draft-ietf-ace-coap-est-17: No Objection > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for this well written document. And thank you for addressing my > points in github. > > A remaining comment (which might or might not have been resolved): > > 5.1. Discovery and URIs > > Clients and servers MUST support the short resource EST-coaps URIs. > > Just to clarify: the original EST URIs are prohibited in COAP-EST? > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > Attachments: > * smime.p7s From nobody Mon Jan 6 10:00:19 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 40838120996; Mon, 6 Jan 2020 10:00:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <157833360921.8003.6238594444996424752@ietfa.amsl.com> Date: Mon, 06 Jan 2020 10:00:09 -0800 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-18.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 18:00:15 -0000 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 : EST over secure CoAP (EST-coaps) Authors : Peter van der Stok Panos Kampanakis Michael C. Richardson Shahid Raza Filename : draft-ietf-ace-coap-est-18.txt Pages : 51 Date : 2020-01-06 Abstract: Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-coap-est-18 https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-18 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/ From nobody Mon Jan 6 10:12:48 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7655A120982; Mon, 6 Jan 2020 10:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=O0Z6AsNS; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=l7lG/7EP Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyLAtUd_8HTP; Mon, 6 Jan 2020 10:12:36 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 081BB1209D6; Mon, 6 Jan 2020 10:12:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8036; q=dns/txt; s=iport; t=1578334345; x=1579543945; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=nHteL7zfTilLAGEsxcT/5RL8udipvrxT54byahho+vk=; b=O0Z6AsNSvGXNLwKehqGd8/JknHigFomMiGARt6uYRL/41f5bs7VODhtt sT3RS6zWrdvwYPEMorouIIaDU6X9YC735iGlny3kDELZqQcaK7mcASvUt /wK0dH/QGPixov2sYyFgV3DCuyDkQp9tTJBpNmWHmxokd8DGzMH/Q2pq8 g=; X-Files: smime.p7s : 4024 IronPort-PHdr: =?us-ascii?q?9a23=3AldH9+BJfy81HSlmncdmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXFX4JfvyZiozNM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B9HgAfeBNe/4wNJK1mHQEBDAErBQU?= =?us-ascii?q?BDQkBgUuBUlAFbCstIAQLKodPA4sCToIRmA2CUgNUAgcBAQEJAwEBGAsKAgE?= =?us-ascii?q?BhEACTAEEgRgkOBMCAw0BAQQBAQECAQUEbYU3DIIpgzUBAQEBAwEBEC4BASw?= =?us-ascii?q?MCwQCAQgRBAEBLwIlCx0IAgQBEggGFIMBgXlNAx8PAQIMolQCgTiIYYIngn4?= =?us-ascii?q?BAQWBOQIOQYJ4GIIFBwmBNgGBUoNKhnwagUE/gRFHgkw+gmQBAQIBARiBSYN?= =?us-ascii?q?AgiyNOxuJRJgDCoI2g2GCODVmjwGCRnaHB5AYjlOIU5IGAgQCBAUCDgEBBYF?= =?us-ascii?q?pIoFCDghwFRohgmwJRxgNkQWFFIU/dIEojT8BAQ?= X-IronPort-AV: E=Sophos;i="5.69,403,1571702400"; d="p7s'?scan'208";a="695679863" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Jan 2020 18:12:24 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 006ICOit000909 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 6 Jan 2020 18:12:24 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 6 Jan 2020 12:12:23 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 6 Jan 2020 13:12:22 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 6 Jan 2020 12:12:22 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iG4PdNhC4gjozE0aBxiPi7YvFmrpIRQLQXa6yV9KEt7TEzO6q1xjcG1SGg/YZiPt0ouPwXUpxHzk6rbLL0J0llVgItpTOTuzbZ6NXXhFeGdDBzeAF2JpA8DZwUhbET6rzgNHSbMraojJS6VPgD7lsocKwvk+jAxjPQ9lYl+85XHqlnwGy13295vwPWDzgGTu1bSvnJU9/0t3c8FNvKhgkfFAxKj1Qs7Jr8IKGDV6Tw1qSLp9vxJcWgRHjrAdBXu4QKnTzOG9+5gotTz2azPaQtbFwacVaTiKUU9zC6VwieUGvaLHffpOMJMmcyIOtfTW59uW21iCQaK6H3AGToIeRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JqCepdQ4lPdI6ehkQEC6RV7Q9JcdabYhd+N1YZR/rS4=; b=Zf8o+ogi7jJsKzgx2Miu4NObCh5T3jMPDKNDo+lcEgb9J09UaHI69n/YKQlSqiccJYBs4ySr7KkQAa9Gkj4gg/YFNcJ/VbK+m7k445hrUUSuszdEmYYU4un9ThrbD+bI1X7K7amtriYMTDyAH2spD6Kl7xhnyT5cRENHmRyAWLrEkIZehe8ebIGDDyFwUDvRUCvYIOZrv33mePbaFfkmyOWZ2IVcX/1qTMxmpRMq+hkXnRS/swjC6QfSjwSHXTK1/sefU0mhPd070b5hT0FqXSjK/dXu5SJpPGpzVJuq+0l0TwXzMly39zYpRlOwX/uTbM5N+VS8ZV6tHVpQxDvgQw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JqCepdQ4lPdI6ehkQEC6RV7Q9JcdabYhd+N1YZR/rS4=; b=l7lG/7EPFbvoWZb6sDea6RXqq9KD6ZRoh7jGN6xyQ02x0HKyzLdlP4x7S/S1XWSUzTuvov+OyzkP0mZm/IoKzz2YKwi/KOT0L98pdLO9Y9iBcYK1aHwcJ4LexpCbArrSztivAa6qZZROGFImVP7zyrGkq0IcUW/ermB+B8rM1v0= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2721.namprd11.prod.outlook.com (52.135.243.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.10; Mon, 6 Jan 2020 18:12:21 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f%7]) with mapi id 15.20.2602.016; Mon, 6 Jan 2020 18:12:21 +0000 From: "Panos Kampanakis (pkampana)" To: "ace@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [Ace] I-D Action: draft-ietf-ace-coap-est-18.txt Thread-Index: AQHVxLtE07rr0EyB+EKjyAxbFxjZSqfd7nmA Date: Mon, 6 Jan 2020 18:12:21 +0000 Message-ID: References: <157833360921.8003.6238594444996424752@ietfa.amsl.com> In-Reply-To: <157833360921.8003.6238594444996424752@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1001::1da] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b3c088f9-d8d8-412a-a2b2-08d792d3f94b x-ms-traffictypediagnostic: BN7PR11MB2721: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0274272F87 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(376002)(136003)(396003)(346002)(13464003)(199004)(189003)(110136005)(66556008)(66476007)(71200400001)(66616009)(66446008)(64756008)(66946007)(76116006)(966005)(52536014)(5660300002)(86362001)(316002)(186003)(8676002)(450100002)(7696005)(81166006)(81156014)(66574012)(2906002)(6506007)(8936002)(478600001)(53546011)(9686003)(33656002)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2721; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: OP6jg8qRKwSw+ShGLsuOz+SfUaXtn537SfCSsyydVxb0eQcfrrePt3CoVD1zabRqPlkur1YybQYcU2BpqWbYXBRPKsTTBa0pEH0Cpo5wkr9lWVhB3n655Q30zR8WXsf2oUTZg6+dBiKSo5ocVNp39EN4RidTs2JuqLBGnP4V9u+DegDyVzjfIpAB7Q2OmvgBO/daI78lIAwpcb/G0eZRYwACgKLiXUWu+fYex1VdPFKLomoZCjCN9BJPrOu+wDVQEKeswOPixn8+AiAonob0fZcu695Thd2g7eJaxOI3C8MzvS2oKIwzcI/Z/5z5xu/QWhXXnqHLfUceJe9rKFhGJ5q2r6eH8Y6AYkPy0q9tJj0vbFLEV+LO+bwFDIYsp65Cl9UPHo+oajQ7lxGVn0ByOune58/5LO+J/z/s3A/PevfYNi9Ggi9/3Bb9PlOwGy7noqzbYirWA4G7m1h3AWett2zrDhudRWtRlurY5aDxBRtOUlUddgFcFD08A6ZYKKw/fncUnA6b1fyPFbekO00l3Yc+e3+oAxlDQRoEJBZ4w+U= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_003F_01D5C492.ED4F6390" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b3c088f9-d8d8-412a-a2b2-08d792d3f94b X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2020 18:12:21.4103 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: P/5uRd5yOZaY+TlJw8bv48wosfc4illLDYuL0cGJRMmMouIOkJGZZ21vgy/EcL3fVISqosctYvL1sEecDkKJsg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2721 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.20, xch-rcd-010.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-coap-est-18.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 18:12:44 -0000 ------=_NextPart_000_003F_01D5C492.ED4F6390 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, This iteration addresses all IESG reviews. More details on the feedback and how we addressed it are in the git issues here Rgs, Panos -----Original Message----- From: Ace On Behalf Of internet-drafts@ietf.org Sent: Monday, January 06, 2020 1:00 PM To: i-d-announce@ietf.org Cc: ace@ietf.org Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-18.txt 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 : EST over secure CoAP (EST-coaps) Authors : Peter van der Stok Panos Kampanakis Michael C. Richardson Shahid Raza Filename : draft-ietf-ace-coap-est-18.txt Pages : 51 Date : 2020-01-06 Abstract: Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-coap-est-18 https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-18 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 Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace ------=_NextPart_000_003F_01D5C492.ED4F6390 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDGkw ggNDMIICK6ADAgECAhBf+HsoK1TcjUKjFbVoya3/MA0GCSqGSIb3DQEBBQUAMDUxFjAUBgNVBAoT DUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNpc2NvIFJvb3QgQ0EgMjA0ODAeFw0wNDA1MTQyMDE3 MTJaFw0yOTA1MTQyMDI1NDJaMDUxFjAUBgNVBAoTDUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNp c2NvIFJvb3QgQ0EgMjA0ODCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBALCauaunrwp3 p+JxtrRmYpR4iEfGYlWEQDK/wKsupRxx1rxue6iqum7SFYhIRZ2i/IPQzLmM4CZocEp43yEXnvRh BckVyM8W2jVhiZRDqISoMZh4m7lObyxTEmzNHa0rJLsxxCv/g0Rvtj0kdwnqvyqoH2pW9iAPEVSX gXWnJc5ZaoJl77fq5+KNdYtu8t1Ppl5inM8QCmTQTm3OK8xb9WClJ0eNafR/zhtw3nAbINZuzaYB qDwS0qk/oGteu44gi3qR47Vo7qDnxAF0qFMLK0qaD2USDoJNjmP97+ubGttTphNgr8J918dsFyXU c/tHZFCBgJRM4b+uSxzfku0uBd8CAQOjUTBPMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/ MB0GA1UdDgQWBBQn88gVHm6aAgkWrSugiWBf2nsvqjAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG 9w0BAQUFAAOCAQEAnZ2EhKNBqXx3DLdTyk5EUGLvVHzTdRcc6ODGSEu2/kw6GYFWsFbuGZZiqlqj ZMH2TlQzxnf+xRy65V0lyvXwk5qDES7my/h0Rf7nBbir59/LS+E3hNq5i5dwHvDii9ew2A6dsWnW KpF7qUlPfuaOldiDJzzVaEkO1J32LuunvuswpKwfRPyVqzMG+31gCt60imOwnKnypLlTAYfQaKQn f6v/6frJQDiIZ7Q5xoRvV8lT27qO7sBDsvgJg27/Zs8+7xezWBglCTRe48vWFLbs8pJvdOQvgSrV kpHg4Jc8MmgFhUvR91fiUh2TGlSfBXDASnFgHkMLYB7+o86BGeELNTCCBG4wggNWoAMCAQICCmEQ gG0AAAAAAA4wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UE AxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTE0MDQwNDIwMjQxOFoXDTI5MDUxNDIwMjU0MlowLDEO MAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVlIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyt9+FkxTFfsjVs3GuWUKBJXl3kxFZ4wMxwbgqx9tXzcqe+fto62A fxHI84Lr7p9Q2cm/PaEvuzwRBzXvuKXZUU7ZsPdToJSALCySZa0Qb6GGa19ACpmlUEQakE3P5kz7 RgaNSOMH1+GtY9fV6CcAFb9uB7JDu2UGL332WV2bEsUsfb3rRLBS4cL8Hu2dWfcdk6erMaZCQjkn 04FixlQsJozbPRTQqI4V6iikG/69rDyeTdbVTK+My/9LnwVsD3GBMiRh7RmrvupxtGiMu8j05Is/ d1OifhWecwvjV3Reg9Lok8bMNJEMAped1weTdVS0X4MsAheosJBld9lS5O4idwIDAQABo4IBhzCC AYMwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFJ+VNrSOXdVLwwrBpymTQ1EG/YlRMBkGCSsG AQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB8G A1UdIwQYMBaAFCfzyBUebpoCCRatK6CJYF/aey+qMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly93 d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jcmwvY3JjYTIwNDguY3JsMFAGCCsGAQUFBwEBBEQw QjBABggrBgEFBQcwAoY0aHR0cDovL3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL2NlcnRzL2Ny Y2EyMDQ4LmNlcjBcBgNVHSAEVTBTMFEGCisGAQQBCRUBFQAwQzBBBggrBgEFBQcCARY1aHR0cDov L3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL3BvbGljaWVzL2luZGV4Lmh0bWwwDQYJKoZIhvcN AQEFBQADggEBAD5OviMaRgKNXmvbigI0C2Ob5QE8Jl2McLIk62Be7IqEZC4bWRWjZxrhFuP94E19 RJojKNLttveiH+dEze1t6oYhVCisbGG8+8hlUARAiiqL/J9uGJ71xT6loqkcAK5xphe7STJLSlgT k0w26fcvDeiA6zhdVHnKhVKkpOJWd9MNByFOnCQyDOK+pcNxLU6IN9TwL1ZoRkdFa11QiCX3Oimk 8YhBrVN+VzGGKtbgZ4fYU6uBo3V3vtshyDpHtGkn1e7f9/TWcY26etFzL33dzaZ4lChlw4l3XkLq 6AfCEDF5djpBdiCRjwpBUIIbCSmyESBvA+sL4j8i1vo/uEartrAwggSsMIIDlKADAgECAgoBhhEi QTzquitVMA0GCSqGSIb3DQEBCwUAMCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBF bXBsb3llZSBDQTAeFw0xOTEyMjAxOTQ5MDJaFw0yMTEyMTkxOTU5MDJaMIGfMSQwIgYDVQQDExtQ YW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkxFDASBgNVBAsTC0Npc2NvIFVzZXJzMRIwEAYDVQQL EwlFbXBsb3llZXMxEzARBgoJkiaJk/IsZAEZEwNjb20xFTATBgoJkiaJk/IsZAEZEwVjaXNjbzEh MB8GCSqGSIb3DQEJAQwScGthbXBhbmFAY2lzY28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAmIHTLIzoAnuMUiHMx8V+PF9JpAcB7zrNHOY1Vj1R1Vx7ty7m9yo9G991T2n7zHo4 UzF6tnB9NxzQOKCY54oqP5KjVGYOPPo+qZ+2rx1GABzdKUF4LwUUKOTf9uXAtvsvIRUc5J/csShT jcUIvtVmiAzWXWRfMYShjBYBVtx/h8fDqAqfFAzd6HG0TcdsN/BRb9k6QEW1afHjPKlRUaDRELyj nFGJZd2OsUJ7/aKMdFmQFd2CAJYzsuwLYjeqJsuGNzBc/k6mzQPf6FW17nz17G41KReU0UdZf2yZ jvimkwCQ/yW8SVTOcGBP+Zk+Lq5EYEGQMu1qtNK/97bXMc5kuwIDAQABo4IBWjCCAVYwDgYDVR0P AQH/BAQDAgTwMAwGA1UdEwEB/wQCMAAwegYIKwYBBQUHAQEEbjBsMDwGCCsGAQUFBzAChjBodHRw Oi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY2VjYS5jZXIwLAYIKwYBBQUHMAGG IGh0dHA6Ly9wa2ljdnMuY2lzY28uY29tL3BraS9vY3NwMB8GA1UdIwQYMBaAFJ+VNrSOXdVLwwrB pymTQ1EG/YlRMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jaXNjb2NlcnRzLmNpc2NvLmNvbS9m aWxlL2NlY2EuY3JsMB0GA1UdEQQWMBSBEnBrYW1wYW5hQGNpc2NvLmNvbTAdBgNVHQ4EFgQUjrl7 6Mrrdw3ZYFiTpZBdtrUm5P4wHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZI hvcNAQELBQADggEBAMhR6xCTygu68lppjWebXTXYznix5961hcmwiJRkPtUIGQ5JQwXyCwq/Juuq yc5ebeq9cQEO5iqyxik/UAQ35BlmKb7SNLi75RtFE/AIZrRsEjTUoO2EtCMQOEMcenWa2XE8fEID BkwzreKeaOchCbDd4L9PvKFht6nDDFtb6VZdWs4ort+J3iFeilVf3oI5MSVi+qroWaFLnLYTQGTn qEjWANfKw3RRBAMdoPCZ+N4eftAk1TWVS08nOsPoKWXtIqX6y0ZPs/EZjBSk57v1TPLpYhEqYGXI oGJlIvzIAfYNoUg8yP8toG5T7x+7hRz0MMUGWcCDsS9PMFxH6SnrUSMxggMNMIIDCQIBATA6MCwx DjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTAN BglghkgBZQMEAgEFAKCCAaQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMjAwMTA2MTgxMjIwWjAvBgkqhkiG9w0BCQQxIgQgsf3q921H51OYG3aOW2qBg8S+n3nCOBkT d4nuVmys1VIwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lz Y28gRW1wbG95ZWUgQ0ECCgGGESJBPOq6K1UwSwYLKoZIhvcNAQkQAgsxPKA6MCwxDjAMBgNVBAoT BUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTCBoAYJKoZIhvcN AQkPMYGSMIGPMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDALBglghkgBZQMEAgEwCwYJKoZIhvcN AQEKMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEA jC/nU3olcaFMBeDNdqHuZgVBjQxhtq5aSL/VZYy/ezstxKTobz2A03noR06Ut4Z98N1S4vhYZhqr 3RbuKSB03yWkfYHEKl2G/4Z4McbPWPTT6Jj0fL2doMdHOxskADCGnRh3E+jSGEpVZe//uwaXFbj2 aSnvWvIumx4YElKAAHyYA68rJHhsnoIDaXXC3j5iweW9rQu0mkYwNi1iOOekEseRSOM8BVRszv/U fPaHS/5ZUwNiqg23g6BEaczCirSUKZxS6Kko748IFW+E3GxtYYFSxZWYZeOI5Kss1c19Tmu5kWpq FzeF3kWtEWcO2WlxbXkZctBX8rw19S87QU9pfwAAAAAAAA== ------=_NextPart_000_003F_01D5C492.ED4F6390-- From nobody Mon Jan 6 10:12:52 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B5B120A0E; Mon, 6 Jan 2020 10:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEmnh64JSAw3; Mon, 6 Jan 2020 10:12:36 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FE3A12094F; Mon, 6 Jan 2020 10:12:21 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 6 Jan 2020 10:12:07 -0800 From: Jim Schaad To: 'Olaf Bergmann' CC: , 'Benjamin Kaduk' , References: <20200102234020.GI35479@kduck.mit.edu> <014601d5c2b8$9947acc0$cbd70640$@augustcellars.com> <878smkrjg0.fsf@wangari> In-Reply-To: <878smkrjg0.fsf@wangari> Date: Mon, 6 Jan 2020 10:12:05 -0800 Message-ID: <000801d5c4bc$cf418110$6dc48330$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHGCRF5nmwiv9SPGwzqJ8qbQfLFcAHlgxMZAtepCeWn13nIkA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 18:12:45 -0000 -----Original Message----- From: Ace On Behalf Of Olaf Bergmann Sent: Monday, January 6, 2020 2:03 AM To: Jim Schaad Cc: ace@ietf.org; 'Benjamin Kaduk' ; = draft-ietf-ace-dtls-authorize.all@ietf.org Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 Jim, Jim Schaad writes: [Ben's review] > We also are potentially in violation of the framework's requirements = with respect to the independent selection of profiles for client/AS and = client/RS interactions -- at present, when DTLS+RPK is used for = client/RS, we require that DTLS+RPK is also used for client/AS, in order = to prove possession of the key. We could perhaps weasel our way out by = saying that the framework's requirement applies at the profile = granularity, and with symmetric PSK we can be fully independent, but we = still need to say something about this property and the interaction with = the framework's requirements. > > [JLS] I am missing where it is saying this. Can you give a pointer? = I don't believe that the POP of the RPK is required at the time that the = token is obtained. The problem is that AS must bind the Access Token to the RPK that the = Client has presented, and the Client must use the very same RPK to = establish the DTLS channel with RS. Otherwise, RS cannot be sure that AS = has issued the Token to the same entity that is currently communicating = with RS. [JLS] What if I do the following sequence of events: 1. The AS is configured with RPK1 for the client and the client is = configured with RPK2 for the AS. 2. The client and the AS run some type of POP algorithm, not currently = specified, to configure RPK3 into the AS for a second RPK to work with = some set of audiences (AUD1). 3. The client then uses RPK1 to authenticate to the AS and asks for a = new token for AUD1 and provides (explicitly or implicitly RPK3). The AS = knows that it is tied to the client due to what happened in step 2. The = AS then creates a new token for AUD1 which contains RPK3 for the client = (and RPK4 for the RS) and returns it. The AS does a current POP for RPK1 when the token is being asked for. The AS did a POP for RPK3 when it was placed into the system. The AS has not done a POP for RPK4 - that was simply configured without = that step ever being done. The ACE framework has no ability for the AS = to do the POP on RPK4 and ensure that it current. The client would do a = POP when the TLS session is created but has to rely on the AS that it is = for the correct RS. Note that the client can never generate a brand new RPK9 and send it to = the AS in the token request because the AS will never have seen this = before and would need to run the POP algorithm of step 2 in order to = assure that it is bound to the correct client and not pulled out of thin = air. RPK9 could not be used to authenticate the token request because = the AS has no idea what client it is tied to. Jim Jim =20 Gr=C3=BC=C3=9Fe Olaf _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Mon Jan 6 10:17:21 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3BBD1200D7 for ; Mon, 6 Jan 2020 10:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=FkvJT6hi; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=ziOVF7Sm Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cfPAIYKhTIs for ; Mon, 6 Jan 2020 10:17:18 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D53861200B3 for ; Mon, 6 Jan 2020 10:17:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8413; q=dns/txt; s=iport; t=1578334637; x=1579544237; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=O1WBqa84K7ijtc7A3QZxKjmxIpj9aw47xdEJ9W2qKtU=; b=FkvJT6hi+7rFm1r0OYQaxowEgrkpdnH2nuZxl6+s+HxPd30p4lUtqM+L P/iANSLNy0Y9bXIPg3/f04IznHmRe5i5Z2kQUHXx6i2cPeoiqn0+Q3BiW OzX8A8KpADiPpD5Cm5lbIhDjj6IkTR8wDsmWWpErrjCks8MZU6ZQy8dRD A=; X-Files: smime.p7s : 4024 IronPort-PHdr: =?us-ascii?q?9a23=3A0nMw3RdGxOQWsjcb5s5E2iK/lGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGQD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/dy8zGdxLUlZN9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BeOwCveBNe/4kNJK1mHAEBAQwBKwE?= =?us-ascii?q?EBAEBAgEHAQEBAQcBAYFLgVJQBWwrLSAECyqHTwOLAk6CEZgNglIDVAIHAQE?= =?us-ascii?q?BCQMBARgNCAIBAYRAAkwBBIEYJDgTAgMNAQEEAQEBAgEFBG2FNwELgimDNQE?= =?us-ascii?q?BAQEDAQEQLgEBLAwLBAIBCBEEAQEvAiULHQgCBBMIBhSDAYF5TQMfDwECDKJ?= =?us-ascii?q?VAoE4iGGCJ4J+AQEFgTkCDkGCeBiCBQcJgTYBgVKDSoZ8GoFBP4ERR4JMPoJ?= =?us-ascii?q?kAQECAQEYgUmDQIIsjTsbiUSYAwqCNoNhgjg1Zo8BgkZ2hweQGI5TiFOSBgI?= =?us-ascii?q?EAgQFAg4BAQWBaSKBQg4IcBUaIYJsCUcYDZEFhRSFP3SBKI0/AQE?= X-IronPort-AV: E=Sophos;i="5.69,403,1571702400"; d="p7s'?scan'208";a="405616264" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Jan 2020 18:17:16 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 006IHG3N009182 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 6 Jan 2020 18:17:16 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 6 Jan 2020 12:17:15 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 6 Jan 2020 12:17:14 -0600 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 6 Jan 2020 13:17:14 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VRO/TgTI0vbM7Laa+elumQ4ouK/LXomdrTHDR6skoC6pRmcrxqILUTDd4HCvFS/tBBEpRkp5IurhD0uqFFDqct682gggn5Sr6NJwQjm0YwfGMG1Ltje38TpqMlfCYkrl54wXOVsmHwqTc6a+6XAPmCcofHL4bJvZUngSPtB+vspHM3KiM4CSjrDLpBbawMPXB8CIfNhJcjL0wV5uJFFrVQsKRGTwhSuM/Pg8QxDiturclNJ2p5yzA0AqS/p1KrkGsEHMN+qzoSlBruiE/hrs00lP1gokmWmoZWkgJKl4dOwJ3Lj67bUDTf5xxTk6alubvQPIlGwj+ggZdVGpY38VlQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AYIhWkGSHQ6l2a9Ko6Q/Uj5m/on3BkHdELMxxiG6ckU=; b=LBjVSByUoo46jFI+gVZ01PvSe1nf/RBghfbTTTuf4bbfXWN7KumwRpiSPH1RPLdwqpPHwgTXRxFxDn6K9Tp0D5CJDs82Tqp/qqeRiHjfm9u/pvpdk90hxEiH4rIgrSrGl+qjM4f9H5Txa9zEZza4h1VWps9QvS91aOnsMW4AHJdtMwb5QdpKE42fFVve3RDvZJwvxz1lsF4801MV0IHGWZ2L4928H83CYMwCGs27WfIZ2i5Mdo0lWsM72aT9OUYwNtyZkPxu/Q7MY3UNdw8BLKFA7Hnz48kV8LChjibY441RiPw51BXkUr2YEP1UD7fjtgvvtiTMfs78rFgyAzOi4Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AYIhWkGSHQ6l2a9Ko6Q/Uj5m/on3BkHdELMxxiG6ckU=; b=ziOVF7SmOVJuhmfX2uqXLpat0oJEFN6KQLCBnVJj11IlW7H2+Hv7C0SDvH6tENWSp2nukAUuW8rUJt5g6gr2mQBaFu3qPUyQxg3qpBIG6WUng+51y11dCBG+1L9Rt/ILP+jUxuw9M+2LtVKZsA2yVlmMq1HYGhd8bjm6/N/3MUs= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2849.namprd11.prod.outlook.com (52.135.246.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.12; Mon, 6 Jan 2020 18:17:14 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::e03c:e55a:c03f:5f4f%7]) with mapi id 15.20.2602.016; Mon, 6 Jan 2020 18:17:14 +0000 From: "Panos Kampanakis (pkampana)" To: "ace@ietf.org" Thread-Topic: [Ace] I-D Action: draft-ietf-ace-coap-est-18.txt Thread-Index: AQHVxLtE07rr0EyB+EKjyAxbFxjZSqfd7nmAgAADBXA= Date: Mon, 6 Jan 2020 18:17:13 +0000 Message-ID: References: <157833360921.8003.6238594444996424752@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1001::1da] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 002c8581-0d2f-4ba7-8bfd-08d792d4a7b8 x-ms-traffictypediagnostic: BN7PR11MB2849: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0274272F87 x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10009020)(376002)(346002)(366004)(136003)(39860400002)(396003)(199004)(189003)(13464003)(5660300002)(8936002)(2940100002)(81156014)(52536014)(316002)(966005)(86362001)(8676002)(81166006)(2906002)(71200400001)(76116006)(66476007)(66556008)(64756008)(6916009)(66446008)(66946007)(66616009)(478600001)(53546011)(9686003)(55016002)(7696005)(33656002)(6506007)(66574012)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2849; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QRr20xSlf9KaHQCJKWO8bTRCFxxC2PiY5NIfW0VZLvddro4V2zdZPNQdyg5ltmhU9nX3RfWKv2G5VC8YscRYsUD12o2Q6wraSL8cum4vsWVTdMMNP8muJTMQMjU+IHrt/VV9uwmGMBh2iDp9mlWxFZaLIxvxkqS0q5kYOiAuXbEiA4UUIWKY1O1xD6Y+RqjH1sEJb4bPsrvC3aVyuWLtHHh+0iocGPQ4shhWPdZHX3WiDm1fuGY/UrLBmyWkT8kgTtb1sJk/wy0ABvgt/BEe/LUBPnTcHwCALKz4p70gNhpUXy/mNaE9jcYAEsDAFXHk+jw+KUejN/QPglltoL+gvoOvXfdErlvLVI8I6YeAlOB4dG4pf9GhMSlV3f6VMnEC5q9ELKA/JvIWdIwN2pTQqYsRheT41ceNtZ8r7UUtkUMRx1Bv1NYnjja/zvvCZ4VXQbSULohyOqdrCvV4uklHLD+FXw+2IGJUjWIJ8x71Yc449wa1WdLDG+jGfSu3H9mSWPOBCdOv/azGA56HKye3OrYBu4kITn6pfHSBlMUs+eqCNDMSK6FG+J0v4oLMMuOo55b9EcuF+mIX/cdgXEG+uvOYfG8j44ozEykOa2EyjCBX1VD42WgJnZIi5XJwSClG2QEzoklUy+lqHULd3L5ylw== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0049_01D5C493.9BBBA420" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 002c8581-0d2f-4ba7-8bfd-08d792d4a7b8 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2020 18:17:13.8767 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TRHJ+/fa7LXRZqoNwy1uMTtKUm9dqEMkAw0IentIownHPDjVr0sOMKM4j0OFHfrxgLFVuf0eq6Obe2hMMBox5A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2849 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-coap-est-18.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 18:17:20 -0000 ------=_NextPart_000_0049_01D5C493.9BBBA420 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sorry, forgot the git link https://github.com/SanKumar2015/EST-coaps/issues?utf8=%E2%9C%93&q=is%3Aissue +%22s+IESG%22 -----Original Message----- From: Ace On Behalf Of Panos Kampanakis (pkampana) Sent: Monday, January 06, 2020 1:12 PM To: ace@ietf.org; i-d-announce@ietf.org Subject: Re: [Ace] I-D Action: draft-ietf-ace-coap-est-18.txt Hello, This iteration addresses all IESG reviews. More details on the feedback and how we addressed it are in the git issues here Rgs, Panos -----Original Message----- From: Ace On Behalf Of internet-drafts@ietf.org Sent: Monday, January 06, 2020 1:00 PM To: i-d-announce@ietf.org Cc: ace@ietf.org Subject: [Ace] I-D Action: draft-ietf-ace-coap-est-18.txt 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 : EST over secure CoAP (EST-coaps) Authors : Peter van der Stok Panos Kampanakis Michael C. Richardson Shahid Raza Filename : draft-ietf-ace-coap-est-18.txt Pages : 51 Date : 2020-01-06 Abstract: Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-coap-est-18 https://datatracker.ietf.org/doc/html/draft-ietf-ace-coap-est-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-coap-est-18 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 Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace ------=_NextPart_000_0049_01D5C493.9BBBA420 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDGkw ggNDMIICK6ADAgECAhBf+HsoK1TcjUKjFbVoya3/MA0GCSqGSIb3DQEBBQUAMDUxFjAUBgNVBAoT DUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNpc2NvIFJvb3QgQ0EgMjA0ODAeFw0wNDA1MTQyMDE3 MTJaFw0yOTA1MTQyMDI1NDJaMDUxFjAUBgNVBAoTDUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNp c2NvIFJvb3QgQ0EgMjA0ODCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBALCauaunrwp3 p+JxtrRmYpR4iEfGYlWEQDK/wKsupRxx1rxue6iqum7SFYhIRZ2i/IPQzLmM4CZocEp43yEXnvRh BckVyM8W2jVhiZRDqISoMZh4m7lObyxTEmzNHa0rJLsxxCv/g0Rvtj0kdwnqvyqoH2pW9iAPEVSX gXWnJc5ZaoJl77fq5+KNdYtu8t1Ppl5inM8QCmTQTm3OK8xb9WClJ0eNafR/zhtw3nAbINZuzaYB qDwS0qk/oGteu44gi3qR47Vo7qDnxAF0qFMLK0qaD2USDoJNjmP97+ubGttTphNgr8J918dsFyXU c/tHZFCBgJRM4b+uSxzfku0uBd8CAQOjUTBPMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/ MB0GA1UdDgQWBBQn88gVHm6aAgkWrSugiWBf2nsvqjAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG 9w0BAQUFAAOCAQEAnZ2EhKNBqXx3DLdTyk5EUGLvVHzTdRcc6ODGSEu2/kw6GYFWsFbuGZZiqlqj ZMH2TlQzxnf+xRy65V0lyvXwk5qDES7my/h0Rf7nBbir59/LS+E3hNq5i5dwHvDii9ew2A6dsWnW KpF7qUlPfuaOldiDJzzVaEkO1J32LuunvuswpKwfRPyVqzMG+31gCt60imOwnKnypLlTAYfQaKQn f6v/6frJQDiIZ7Q5xoRvV8lT27qO7sBDsvgJg27/Zs8+7xezWBglCTRe48vWFLbs8pJvdOQvgSrV kpHg4Jc8MmgFhUvR91fiUh2TGlSfBXDASnFgHkMLYB7+o86BGeELNTCCBG4wggNWoAMCAQICCmEQ gG0AAAAAAA4wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UE AxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTE0MDQwNDIwMjQxOFoXDTI5MDUxNDIwMjU0MlowLDEO MAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVlIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyt9+FkxTFfsjVs3GuWUKBJXl3kxFZ4wMxwbgqx9tXzcqe+fto62A fxHI84Lr7p9Q2cm/PaEvuzwRBzXvuKXZUU7ZsPdToJSALCySZa0Qb6GGa19ACpmlUEQakE3P5kz7 RgaNSOMH1+GtY9fV6CcAFb9uB7JDu2UGL332WV2bEsUsfb3rRLBS4cL8Hu2dWfcdk6erMaZCQjkn 04FixlQsJozbPRTQqI4V6iikG/69rDyeTdbVTK+My/9LnwVsD3GBMiRh7RmrvupxtGiMu8j05Is/ d1OifhWecwvjV3Reg9Lok8bMNJEMAped1weTdVS0X4MsAheosJBld9lS5O4idwIDAQABo4IBhzCC AYMwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFJ+VNrSOXdVLwwrBpymTQ1EG/YlRMBkGCSsG AQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB8G A1UdIwQYMBaAFCfzyBUebpoCCRatK6CJYF/aey+qMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly93 d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jcmwvY3JjYTIwNDguY3JsMFAGCCsGAQUFBwEBBEQw QjBABggrBgEFBQcwAoY0aHR0cDovL3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL2NlcnRzL2Ny Y2EyMDQ4LmNlcjBcBgNVHSAEVTBTMFEGCisGAQQBCRUBFQAwQzBBBggrBgEFBQcCARY1aHR0cDov L3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL3BvbGljaWVzL2luZGV4Lmh0bWwwDQYJKoZIhvcN AQEFBQADggEBAD5OviMaRgKNXmvbigI0C2Ob5QE8Jl2McLIk62Be7IqEZC4bWRWjZxrhFuP94E19 RJojKNLttveiH+dEze1t6oYhVCisbGG8+8hlUARAiiqL/J9uGJ71xT6loqkcAK5xphe7STJLSlgT k0w26fcvDeiA6zhdVHnKhVKkpOJWd9MNByFOnCQyDOK+pcNxLU6IN9TwL1ZoRkdFa11QiCX3Oimk 8YhBrVN+VzGGKtbgZ4fYU6uBo3V3vtshyDpHtGkn1e7f9/TWcY26etFzL33dzaZ4lChlw4l3XkLq 6AfCEDF5djpBdiCRjwpBUIIbCSmyESBvA+sL4j8i1vo/uEartrAwggSsMIIDlKADAgECAgoBhhEi QTzquitVMA0GCSqGSIb3DQEBCwUAMCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBF bXBsb3llZSBDQTAeFw0xOTEyMjAxOTQ5MDJaFw0yMTEyMTkxOTU5MDJaMIGfMSQwIgYDVQQDExtQ YW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkxFDASBgNVBAsTC0Npc2NvIFVzZXJzMRIwEAYDVQQL EwlFbXBsb3llZXMxEzARBgoJkiaJk/IsZAEZEwNjb20xFTATBgoJkiaJk/IsZAEZEwVjaXNjbzEh MB8GCSqGSIb3DQEJAQwScGthbXBhbmFAY2lzY28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAmIHTLIzoAnuMUiHMx8V+PF9JpAcB7zrNHOY1Vj1R1Vx7ty7m9yo9G991T2n7zHo4 UzF6tnB9NxzQOKCY54oqP5KjVGYOPPo+qZ+2rx1GABzdKUF4LwUUKOTf9uXAtvsvIRUc5J/csShT jcUIvtVmiAzWXWRfMYShjBYBVtx/h8fDqAqfFAzd6HG0TcdsN/BRb9k6QEW1afHjPKlRUaDRELyj nFGJZd2OsUJ7/aKMdFmQFd2CAJYzsuwLYjeqJsuGNzBc/k6mzQPf6FW17nz17G41KReU0UdZf2yZ jvimkwCQ/yW8SVTOcGBP+Zk+Lq5EYEGQMu1qtNK/97bXMc5kuwIDAQABo4IBWjCCAVYwDgYDVR0P AQH/BAQDAgTwMAwGA1UdEwEB/wQCMAAwegYIKwYBBQUHAQEEbjBsMDwGCCsGAQUFBzAChjBodHRw Oi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY2VjYS5jZXIwLAYIKwYBBQUHMAGG IGh0dHA6Ly9wa2ljdnMuY2lzY28uY29tL3BraS9vY3NwMB8GA1UdIwQYMBaAFJ+VNrSOXdVLwwrB pymTQ1EG/YlRMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jaXNjb2NlcnRzLmNpc2NvLmNvbS9m aWxlL2NlY2EuY3JsMB0GA1UdEQQWMBSBEnBrYW1wYW5hQGNpc2NvLmNvbTAdBgNVHQ4EFgQUjrl7 6Mrrdw3ZYFiTpZBdtrUm5P4wHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZI hvcNAQELBQADggEBAMhR6xCTygu68lppjWebXTXYznix5961hcmwiJRkPtUIGQ5JQwXyCwq/Juuq yc5ebeq9cQEO5iqyxik/UAQ35BlmKb7SNLi75RtFE/AIZrRsEjTUoO2EtCMQOEMcenWa2XE8fEID BkwzreKeaOchCbDd4L9PvKFht6nDDFtb6VZdWs4ort+J3iFeilVf3oI5MSVi+qroWaFLnLYTQGTn qEjWANfKw3RRBAMdoPCZ+N4eftAk1TWVS08nOsPoKWXtIqX6y0ZPs/EZjBSk57v1TPLpYhEqYGXI oGJlIvzIAfYNoUg8yP8toG5T7x+7hRz0MMUGWcCDsS9PMFxH6SnrUSMxggMNMIIDCQIBATA6MCwx DjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTAN BglghkgBZQMEAgEFAKCCAaQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMjAwMTA2MTgxNzEyWjAvBgkqhkiG9w0BCQQxIgQgYt5ur54dAJK/P5Q2R5BXpwPmmPfMA+ss GwWbX2r5dlkwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lz Y28gRW1wbG95ZWUgQ0ECCgGGESJBPOq6K1UwSwYLKoZIhvcNAQkQAgsxPKA6MCwxDjAMBgNVBAoT BUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTCBoAYJKoZIhvcN AQkPMYGSMIGPMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDALBglghkgBZQMEAgEwCwYJKoZIhvcN AQEKMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEA KqcqreMVNdsPomngEDnp4rlGdTPtxPctY+s8ZcJiFqLhaSdudfgA93akmKeE8biQjIiUykbbCD4X zXuK+o2VBFSCCPJX4rvfdA9s5b54pSNbIR4i8JWc46zq2Rw2qkgKfYKxA3F4JCfVZPavZid0z4lq Ya8Jx66gswJwqawkvzOCnDsnP7dWH2k0NMFinBceN+96zaJb3zJkiCYTX/15QIXwFXI4fXvjjzb7 pTQlTHB912GHWDV50wKe8RTli/9lFFbJ/iLfNTaX4JphD3TKsFZ1xAvhyA9F12fOuXDZ+FjzkBY8 RhVE7E4Bq1yn+/xd9E24VFXnpiSryRY2Pub3igAAAAAAAA== ------=_NextPart_000_0049_01D5C493.9BBBA420-- From nobody Mon Jan 6 12:52:54 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D027D12007A; Mon, 6 Jan 2020 12:52:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach via Datatracker To: "The IESG" Cc: draft-ietf-ace-coap-est@ietf.org, Jim Schaad , ace-chairs@ietf.org, ietf@augustcellars.com, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <157834397179.8020.11361257360430464714.idtracker@ietfa.amsl.com> Date: Mon, 06 Jan 2020 12:52:51 -0800 Archived-At: Subject: [Ace] Adam Roach's No Objection on draft-ietf-ace-coap-est-18: (with COMMENT) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 20:52:52 -0000 Adam Roach has entered the following ballot position for draft-ietf-ace-coap-est-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my discuss and comments! From nobody Tue Jan 7 08:40:18 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0553512095E; Tue, 7 Jan 2020 08:40:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqozIfN-gWu1; Tue, 7 Jan 2020 08:40:04 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8819F120052; Tue, 7 Jan 2020 08:38:56 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 007Gcq85029119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 7 Jan 2020 11:38:54 -0500 Date: Tue, 7 Jan 2020 08:38:51 -0800 From: Benjamin Kaduk To: draft-ietf-ace-oscore-profile.all@ietf.org Cc: ace@ietf.org Message-ID: <20200107163851.GV57294@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: [Ace] AD review of draft-ietf-ace-oscore-profile-08 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 16:40:12 -0000 Hi all, Some high-level points before the section-by-section commentary: I'm a little confused by the registry we are creating in Section 9.2. While it's clear that we need something to specify the CBOR map key labels to encode the structure for transit, it's not clear that we need easy extensibility vs. a fixed table. A registry implies expectations of future additions, but draft-ietf-core-object-security did not feel a need to make a registry for future extensions; what has changed in the past few months that makes extensibility needed now? Why is this document the right place to create the registry as opposed to that one? We are in some sense defining a new substructure within "kid" values (a CBOR-encoded array of one or two elements) for usage by things using this profile. That's probably not problematic, as the "kid" can be an arbitrary bstr and its interpretation is up to the recipient -- any recipient that implements this profile will know to handle the substructure, but it does feel a little unusual and perhaps worth an early note. (IIUC, we also need to be careful about actually providing the bstr framing in our examples.) I'm concerned about the usage of "cnonce" to carry both N1 and N2, neither of which correspond to the "cnonce" behavior in the core framework; I think we should pick a different parameter name for the differeng semantic usage. Specifically, the core-framework "cnonce" is a tool to give RSes some modicum of replay protection -- it verifies that the client's authorization in the token is "fresh", since the token includes the random nonce generated by the RS and conveyd to the AS via the client. This document uses a parameter named "cnonce" in two ways: (1) to convey the client-generated nonce N1 to the RS in the authz-info request; this is giving the client contributory behavior to the ephemeral randomness input to the Security Context computation but does not provide any sort of replay-protection in and of itself (2) to convey the RS-generated nonce N2 back to the client in the authz-info response; this does serve as replay protection in some sense, but in that it serves to cause repeated posting of the same token (as might occur in a replay attack) to generate a different OSCORE context (due to the RSes contributory nature) so that the resulting key material will be unique for a given association, as opposed to detecting and blocking replay outright. I think all three uses should have distinct parameter names, based on my current understanding. We mention several times about getting protection from AEAD nonce/key reuse, but to some extent leave it to the reader to figure out how that works. Specifically, the only guidance we give on nonce selection is for our N1 and N2 that go into the Master Salt; we don't say how varying the Master Salt like that will cause the generated keys and (common) IVs to differ across runs, thus by construction preventing the collision of (key, nonce) pairs. (Implementation carelessness that just reuses key+nonce for a given Security Context is still possible, of course.) In a related vein, we do not get into full detail about the cryptographic role played by N1 and N2, so as to make the reader confident that our 64-bit recommendation does provide full Internet-grade security (as opposed to a weakened "IoT" variant). I'm not specifically concerned, but we may get some reviewers asking for more detail. I am, however, concerned about the exposure to an RFC 3552-style attacker for unprotected authz-info responses. There are two main aspects I'm concerned about: identifier selection and nonce selection. Letting the server override the client's idea of its own identity (even when the AS has given the client an identifier!) seems to increase the risk of a client being tricked into impersonating a different client, and the stated justification (letting the RS preserve uniqueness) doesn't seem to hold up in our one-AS-per-RS stated scope, where the AS can equally well do so. Based on what I know right now, it doesn't feel like we're at the right point on the cost/benefit curve. For the nonce selection, this comes into play due to the lack of injectivity for the mapping of initial AS-generated salt, N1, and N2 into the Master Salt. Specifically, if a client chooses an N1 that's a prefix of some other N1 that was used, then the attacker can send an "N2" that contains the tail end of that other N1 plus the actual N2 picked by the server in that other exchange, causing a full nonce collision and having the AS-generated portion be the only difference in Master Salt between security contexts. Using a length prefix for the fields being concatenated provides injectivity and thwarts this type of attack. There are a few places where I'm not entirely sure how the protocol flow works for the case where the RS is (re)assigning the clientId; I've tried to note them in the section-by-section comments. On to the section-by-section notes: Section 1 I'd suggest noting that this is a symmetric-crypto-based scheme in some manner (e.g., that the AS is assigning a shared symmetric key used as the OSCORE master secret), and/or that asymmetric PoP semantics are not possible with this mechanism (or OSCORE in general). I'd also suggest noting that proof of possession is not done by a dedicated protocol element, but rather occurs implicitly based on knowledge of the OSCORE Security Context. (This is essentially analogous to Kerberos, but a reference is not strictly needed.) We do have a good treatment in toplevel Section 4, but it might be worth saying earlier. Section 2 [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 TLS or DTLS MAY be used additionally or instead. Since the client/AS and client/RS profile are supposed to be completely severable, I don't think we should use "MAY" here; perhaps "but other protocols (such as TLS or DTLS) can be used as well". Once the client has retrieved the access token, it generates a nonce N1 and posts both the token and N1 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. Do we want to say explicitly that there is no cryptographic protection applied for this POST to authz-info? which contains a nonce N2 in a CBOR map. Moreover, the server concatenates N1 with N2 and appends the result to the Master Salt in the Security Context (see section 3 of [I-D.ietf-core-object-security]). The RS then derives the complete Security Context associated with the received token from it plus the parameters received in the AS, following section 3.2 of [I-D.ietf-core-object-security]. This passage feels strange to me, probably because it seems to use "Master Salt" to both the portion with and without N1+N2, and also because it does not introduce "the Master Salt" as a term or some other object that deserves the definite article. Would it be equivalent to say "Moreover, the server concatenates the input salt, N1, and N2 to obtain the Master Salt of the OSCORE Security Context (see section 3 of [I-D.ietf-core-object-security]" instead? (Though the details may yet change based on later comments...) Is "from it" the resulting Master Salt? There seems to be a word or two missing in "the parameters received in the AS". (Presumably these parameters are contained in the token?) After receiving the nonce N2, the client concatenates it with N1 and appends the result to the Master Salt in its Security Context (see section 3 of [I-D.ietf-core-object-security]). The client then derives the complete Security Context from the nonces plus the parameters received from the AS. Similarly, IIUC we should be able to word this so that the "Master Salt" is unique (and includes the nonces), as opposed to having it apparently refer to both the pre- and post-nonce-includion strings. Are these "parameters" received from the AS in the token response? Finally, the client sends a request protected with OSCORE to the RS. If the request verifies, then this Security Context is stored in the server, and used in the response, and in further communications with the client, until token expiration. This Security Context is discarded if the same token is re-used to successfully derive a new Security Context. The conditional on storing the Security Context only if the request verifies reads oddly to me, as the RS seems to have needed to store some amount of security context information for the period betweeen receiving the token and receiving the authenticated request, as a prerequisite to being able to verify the request. Also, is this security context discarded if a new token from the same client is successfully used? The use of random nonces during the exchange prevents the reuse of AEAD nonces and keys with different messages, in case of re- derivation of the Security Context both for Clients and Resource Servers from an old non-expired access token, e.g. in case of re-boot of either the client or RS. In fact, by using random nonces as part This sentence is pretty long and a little hard to parse. I'd suggest something more like: % The use of random nonces during the exchange prevents the reuse of % an AEAD nonces/key pair for two different messages. This situation % might occur when client and RS derive a new Security Context from an % existing (non-expired) access token, as might occur when either party % has just rebooted. [...] I'd also consider s/In fact/Instead/ since we are contrasting the previously described hypothetical (bad) scenario with what actually happens. of the Master Salt, the request to the authz-info endpoint posting the same token results in a different Security Context, since Master Secret, Sender ID and Recipient ID are the same but Master Salt is different. Therefore, the main requirement for the nonces is that nit: [more usage of "Master Salt" for pre- and post-nonce forms] I'd also suggest to s/since/since even though the/ (and the s/but/the/ needed to fix up the end of the sentence). I also want to check my understanding: this "different Security Context" is still going to use the same identifiers for the endpoints, and will just have different keys/IVs/etc? This would tie in to the (later) recommendation to have such a new Security Context completely replace the old one, since otherwise we'd have to resort to trial decryption to determine which Security Context to use for processing a given message. 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. I guess the focus on "good amount of randomness" is trying to emphasize that we merely need to avoid a single node accidentally producing the same value, as opposed to a stricter property of unguessability by an on-path attacker? Or is unguessability also needed when the attacker can delay traffic? Section 3 Section 3.2 of [I-D.ietf-core-object-security] defines how to derive a Security Context based on a shared master secret and a set of other parameters, established between client and server, which the client receives from the AS in this exchange. The proof-of-possession key We say that the client gets the OSCORE parameters from the AS in the token response; where do we say how the RS gets the OSCORE parameters from the AS? Section 3.1 The client MUST send this POST request to the token endpoint over a secure channel that guarantees authentication, message integrity and confidentiality (see Section 5). (The framework already requires this, so we may not need the "MUST" keyword again, though I'm not proposing to remove all mention of the need for these properties.) An example of such a request, in CBOR diagnostic notation without the tag and value abbreviations is reported in Figure 2 nit: only the payload is using CBOR diagnostic notation; the headers are using CoAP notation. If the client wants to update its access rights without changing an existing OSCORE Security Context, it MUST include in its POST request to the token endpoint a req_cnf object. The req_cnf MUST include a kid field carrying a CBOR array object containing the client's identifier (assigned in section Section 3.2) and optionally the context identifier (if assigned in section Section 3.2). The CBOR I'm not sure the best way to write a clear description that includes the "bstr" framing for "kid". Also, nit: the "assigned" language in the parentheticals feels weird to me, here. What's the workflow when the RS has overridden the AS's idea of the clientId? Does the client have to remember the original AS-assigned clientId and use it here instead of the RS-assigned one? These identifiers can be used by the AS to determine the shared secret to construct the proof-of-possession token and therefore MUST identify a symmetric key that was previously generated by the AS as a shared secret for the communication between the client and the RS. nit: I suggest s/shared secret to construct/shared secret bound to/ Also, I think the AS will need to use some of the other token request parameters (e.g., req_aud) in order to determine the client and RS for which it needs to retrieve the shared PoP key. We might want to mention that as well. The AS MUST verify that the received value identifies a proof-of- possession key and token that have previously been issued to the requesting client. If that is not the case, the Client-to-AS request nit: It's not clear that we need it to identify a specific token, just a key. (And in fact for multiple successive access-rights updates, there will be more than one previous token.) The "kid" "req_cnf" member in Figure 4's example does not include the bstr wrapper that draft-ietf-ace-cwt-proof-of-possession suggests is required. Section 3.2 Moreover, the AS MUST provision the following data: It's frequently the case in IETF documents that "provision" is a euphimism for "out-of-band configuration", so if we mean "include in the token response" it's probably better to say that directly. Additionally, the AS MAY provision the following data, in the same response. When the AS does not do so, how are these parameters determined? The OSCORE_Security_Context is a CBOR map object, defined in Section 3.2.1. The master secret MUST be communicated as the 'ms' field in the OSCORE_Security_Context in the 'cnf' parameter of the access token response as defined in Section 3.2 of [I-D.ietf-ace-oauth-params]. The AEAD algorithm MAY be included as nit: s/in the OSCORE_Security_Context/in the OSCORE_Security_Context field/, I think? the 'alg' parameter in the OSCORE_Security_Context; the HKDF algorithm MAY be included as the 'hkdf' parameter of the OSCORE_Security_Context, a salt MAY be included as the 'salt' parameter of the OSCORE_Security_Context, and the replay window type and size MAY be included as the 'rpl' of the OSCORE_Security_Context, as defined in Section 3.2.1. I think we want to reword all of these, as I understand what we're doing to be defining the parameters in which these values are conveyed, if they are conveyed at all. Just saying " MAY be conveyed in " has the connotation that might alternatively be conveyed in some other that is not mentioned. The relevant MAY for our purposes is the one above the list -- "the AS MAY provision the following data". The same parameters MUST be included as metadata of 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_Security_Context structure defined above MUST be placed in the 'cnf' claim of this token. nit: "metadata of the access token" sounds like it's trying to be a term of art, but it is not presently used as such. s/metadata/attributes/ would, IIUC, be more in keeping with OAuth 2.0 tradition. not-nit: the second sentence seems redundant with the second sentence of the previous paragraph. The AS MUST also assign an identifier to the RS (serverId), MAY assign an identifier to the client (clientId), and MAY assign an identifier to the context (contextId). These identifiers are then used as Sender ID, Recipient ID and ID Context in the OSCORE context as described in section 3.1 of [I-D.ietf-core-object-security]. The couple (client identifier, context identifier) MUST be unique in the set of all clients on a single RS. Moreover, when assigned, serverId, clientId and contextId MUST be included in the OSCORE_Security_Context, as defined in Section 3.2.1. [Any time we're assigning identities we have to say something about the privacy properties thereof, or a bunch of reviewers will complain.] Is the Recipient ID expected to be stable/persistent for a given RS as seen by all clients? nit: "all clients on a single RS" reads oddly to me; maybe s/on/of/? nit: I'd suggest to replace "couple" with "tuple" or "pair". nit: serverId is always assigned by the AS, so the "when assigned" doesn't quite bind properly, grammar-wise. While the clientId is "always assigned" by the time of the Master Secret derivation, this is just discussing the AS token response, so we can't necessarily assume it's assigned here, at least with the current protocol spec. OSCORE requires a Sender ID and Recipient ID, but we only have it as optional for the AS to assign the clientId -- what does OSCORE use as the Sender/Recipient ID when the AS does not assign a clientId? When certain fields are optional, we typically have to ask whether it's possible for the two parties to disagree about whether the field is present. IIUC, the OSCORE context derivation procedure includes enough information to prevent that possibility, but it would be good if someone would confirm that. We assume in this document that a resource is associated to one single AS, which makes it possible to assume unique identifiers for each client requesting a particular resource to a RS. If this is not I feel like this might be more clear if we can frame it in terms of the AS enforcing the uniqueness of client identifiers (or, if you will, that we delegate the enforcement thereof to the AS...) the case, collisions of identifiers may appear in the RS, in which case the RS needs to have a mechanism in place to disambiguate identifiers or mitigate their effect. nit: s/appear in/occur at/ nit: s/mitigate their effect/mitigate the effect of the collisions/ Note that in Section 4.3 C sets the Sender ID of its Security Context to the clientId value received and the Recipient ID to the serverId value, and RS does the opposite. (The way this is written implicitly assumes that both clientId and serverId are received from the AS.) Figure 5 shows an example of such an AS response, in CBOR diagnostic notation without the tag and value abbreviations. I'd suggest s/such an AS response/an AS token response/ "access_token" : h'a5037674656d7053656e73 ...' (remainder of access token omitted for brevity)', In addition to the invalid-CBOR-diagnostic-notation-syntax comment, we also have unbalanced quotes. "profile" : "coap_oscore", "expires_in" : "3600", "cnf" : { "OSCORE_Security_Context" : { "alg" : "AES-CCM-16-64-128", "clientId" : b64'qA', "serverId" : b64'Qg', Any reason to prefer b64'qA' over h'a8' which is shorter? If the client has requested an update to its access rights using the same OSCORE Security Context, which is valid and authorized, the AS MUST omit the 'cnf' parameter in the response, and MUST carry the client identifier and optionally the context identifier in the 'kid' field in the 'cnf' parameter of the token, with the same structure I think we should be careful about referring to this as "optionally the context identifier" -- the choice for whether there is a context identifier is made once (at initial issuance), and subsequent usage depends on whether one has been allocated or not. It's not like the AS can decide at runtime "I gave you a context identifier for your original security context, but I don't feel like giving it to you again" -- the derived keys won't match up and it won't be reusable as the same security context. Also, I'm not sure this is fully defined for the case when the RS overrides the AS's clientId assignment, as the kid array in the token needs to be the value the RS will know, but the kid in req_cnf needs to be the one the AS knows, and we don't really define a mechanism for the AS to be able to do translation from one to the other. defined in Figure 3. These identifiers need to be provisioned, in order for the RS to identify the previously generated Security Context. nits: there's only one (not "these") identifier in the token, and nothing in the token response; and a similar remark about "provisioned" as was made above. Figure 9 shows an example CWT, containing the necessary OSCORE parameters in the 'cnf' claim for update of access rights, in CBOR diagnostic notation without tag and value abbreviations. { "aud" : "tempSensorInLivingRoom", "iat" : "1360189224", "exp" : "1360289224", "scope" : "temperature_h", "cnf" : { "kid" : b64'qA' I don't think this "kid" is a valid CBOR bstr wrapping the one- or two-element array. Section 3.2.1 [I-D.ietf-core-object-security]). The OSCORE_Security_Context object can either be encoded as JSON object or as CBOR map. In both cases, nits "a JSON object", "a CBOR map". defined below. All parameters are optional. Table 1 provides a summary of the OSCORE_Security_Context parameters defined in this section. They're optional to appear in the OSCORE_Security_Context object that's included in a "cnf" value, but not necessarily optional for OSCORE to be usable. What do we do for OSCORE when any given parameter is not present in this structure? (Also, doesn't the AS always have to provide things like 'ms' and 'serverId'?) | hkdf | 4 | bstr / int | COSE | OSCORE HKDF | | | | | Algorithm | value | | | | | Values | | | | | | (HMAC-based) | | Should be tstr, not bstr, right? Also, why do we need the string form of either hkdf or alg? More possibilities makes the decoder more complicated and increases the attack surface. | rpl | 8 | bstr / int | | OSCORE Replay | | | | | | Window Type | | | | | | and Size | Should just be bstr (not int), right? hkdf: This parameter identifies the OSCORE HKDF Algorithm. For more information about this field, see section 3.1 of [I-D.ietf-core-object-security]. The values used MUST be registered in the IANA "COSE Algorithms" registry and MUST be HMAC-based HKDF algorithms. The value can either be the integer It's a little unfortunate that we basically are relying on "I know it when I see it" for determining which algorithms are HKDF algorithms. Also, "HKDF" expands to "HMAC-based Extract-and-Expand Key Derivation Function", i.e., is definitionally HMAC-based. So this should be reworded to reflect the actual intent. alg: This parameter identifies the OSCORE AEAD Algorithm. For more information about this field, see section 3.1 of [I-D.ietf-core-object-security] The values used MUST be registered in the IANA "COSE Algorithms" registry and MUST be AEAD algorithms. The value can either be the integer or the text Similarly, this seems to be "I know it when I see it". 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 [I-D.ietf-core-object-security]. In JSON, the "contextID" value is a Base64 encoded byte string. In CBOR, the "contextID" type is bstr, and has label 7. Do we need to forbid present-but-empty contextIds in order to avoid cryptographic collision with absent-contextId? rpl: This parameter is used to carry the OSCORE value, encoded as a bstr. This parameter identifies the OSCORE Replay Window Size and Type value, which is a byte string. For more information about this field, see section 3.1 of [I-D.ietf-core-object-security]. In JSON, the "rpl" value is a Base64 encoded byte string. In CBOR, the "rpl" type is bstr, and has label 8. I tried to follow the reference, but I couldn't really find a description of the encoding for this as a byte string (especially noteworthy since we claim that it represents both size and type). (Relatedly, I'm not sure why it's allowed to be either bstr or int.) Section 4 Can we get some CDDL or similar for both C-to-RS and RS-to-C (in the respective subsections)? I'd naively expect a section titled "Client-RS Communication" to include some discussion of normal protected OSCORE request/response pairs once the security context is fully established, but this initial section basically only talks about the authz-info interaction and disclaims that the subsections will cover anything else. 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 posts it together with the token that includes the materials provisioned by the AS to the RS. The RS then derives a nonce N2 and use Section 3.2 of nits: "provisioned" again, and the RS is going to be generating a nonce from scratch, not deriving one from ... anything else, really. [I-D.ietf-core-object-security] to derive a security context based on a shared master secret and the two nonces, established between client and server. (The shared master secret is part of what the AS provisions^Wgives to the RS, right?) Note that the proof-of-possession required to bind the access token to the client is implicitly performed by generating the shared OSCORE Security Context using the pop-key as master secret, for both client and RS. An attacker using a stolen token will not be able to generate a valid OSCORE context and thus not be able to prove possession of the pop-key. It may be worth saying something roughly equating "proof of possesion performed by the RS" and "the RS authenticating itself to the client", since there is not an external action for server authentication. Also, ISTR getting some pushback on a different document that talked about an attacker with a "stolen token", as something that can steal a token from the client's local storage might also steal the associated key. I forget if we ended up changing to some other phrasing or not, though :( Section 4.1 The client MUST generate a nonce N1 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. The client Why 64 instead of 128? I know that 128 is enough without having to think about it; for 64 we have to be clear about what role the nonce is serving. Note that the use of the payload and the Content-Format is different from what 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 and N1 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 correct CBOR label (e.g., "cwt" for CWT, "jwt" for JWT) and N1 using the 'cnonce' parameter defined in section 5.1.2 of [I-D.ietf-ace-oauth-authz]. That's not what the 'cnonce' parameter is for -- 'cnonce' is protecting the RS against replay, but N1 is protecting the client. I think we need to use a different name (and maybe define some integer map label values?) for this authz-info POST body. The access token MUST be encrypted, since it is transferred from the client to the RS over an unprotected channel. This is probably worth stating in Section 3.2 as well, where we discuss the AS-to-C token response in more detail. Note that a client may be required to re-POST the access token, since an RS may delete a stored access token, due to lack of memory. I'd suggest using the phrase "at any time" and noting that the client will detect this by receiving an AS Request Creation Hints message since the RS treated the request as an Unauthorized Resource Request, perhaps: % Note that a client may be required to re-POST the access token in % order to complete a request, since an RS may delete a stored access % token at any time, for example due to all storage space being % consumed. This situation is detected by the client when it receives % an AS Request Creation Hints response. Payload: { "access_token": h'a5037674656d7053656e73 ...' (remainder of access token omitted for brevity)', "cnonce": h'018a278f7faab55a' } This does not appear to be using either a "cwt" label or "jwt" label, as the second paragraph of the section would have us using. Section 4.2 token. If the token is valid, the RS MUST respond to the POST request with 2.01 (Created). If the token is valid but is associated We probably don't need to repeat the normative requirements from the core framework with normative keywords again. to claims that the RS cannot process (e.g., an unknown scope), or if any of the expected parameters in the OSCORE_Security_Context is Hmm, "associated to claims that the RS cannot process" sounds like we're telling the RS to abort if the token includes any unrecognized claims, which IIUC is at odds with the OAuth 2.0 philosophy of ignoring unrecognized parameters. (Hopefully someone will correct me if I'm misremembering that.) missing (e.g. any of the mandatory parameters from the AS), or if any nit: comma after "e.g.". Additionally, the RS MUST generate a nonce N2 very unlikely to have been previously used with the same input keying material, and send it within the 2.01 (Created) response. The payload of the 2.01 (Created) response MUST be a CBOR map containing the 'cnonce' parameter defined in section 5.1.2 of [I-D.ietf-ace-oauth-authz], set to N2. This profile RECOMMENDS to use a 64-bit long random number as nonce. Moreover, if the OSCORE_Security_Context in the token did not As above, we need to use a different name than 'cnonce', as it's performing a different role (this time, contributing entropy to the master secret). (Also, if we change our recommendation about nonce length above we should do so here as well, of course.) contain a 'clientId' parameter, the RS MUST generate an identifier, unique in the set of all its existing client identifiers, and send it in a 'clientId' parameter in the CBOR map as a CBOR bstr. The RS MAY generate and send a 'ClientId' identifier even though the OSCORE_Security_Context contained such a parameter, in order to guarantee the uniqueness of the client identifier. The RS MUST use I'm not sure I understand the case where the AS wouldn't be able to guarantee uniqueness of ClientId, and wonder if we could simplify by always having the AS make ID assignment. Is there some more background/usage scenarios here that I'm missing? When receiving an updated access token with updated authorization information from the client (see section 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 for the RS to keep track of authorization information for a given client. [this same recommendation is already in the core framework] Section 4.3 the 'clientId' 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, and where salt was received from the AS in Section 3.2. The client MUST set the Master Secret and Recipient ID I think it's general best practice to use an injective mapping of the inputs to the Master Salt value (i.e., length-prefixes for the various fields, since there are no reserved octet values). from the parameters received from the AS in Section 3.2. The client MUST set the AEAD Algorithm, ID Context, HKDF, and Replay Window from the parameters received from the AS in Section 3.2, if present. In case these parameters are omitted, the default values are used as described in section 3.2 of [I-D.ietf-core-object-security]. The Ah, okay; I'd asked about default values earlier. That said, if stock OSCORE ever changes the defaults we'd have to come up with a compatibility story for communication between old/new nodes. client MUST set the Sender ID from the 'clientId in the 2.01 (Created) response, if present; otherwise, the client MUST set the Sender ID from the parameters received from the AS in Section 3.2. [As written, this has the clientId from the RS take precedence over the one from the AS when both are present. I understand that the claimed justification is for the RS to be able to enforce clientId uniqueness, but it still feels risky, since the value from the RS is unauthenticated.] If any of the expected parameters is missing (e.g. any of the mandatory parameters from the AS, or the 'clientId', either received from the AS or in the 2.01 (Created) response from the RS), 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. I think this means "restart at the AS" but it's probably worth being very explicit about it. Also, is there anything to be said about rate-limiting/backoff for persistent missing parameters? 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 this order: Master Salt = salt | N1 | N2, where | denotes byte string concatenation, and [It might be worth breaking this computation off into a standalone piece of text that applies to both C and RS, including the edits for injectivity.] where salt was received from the AS in Section 4.2. The RS MUST set the Master Secret, Sender ID and Recipient ID from the parameters, received from the client in the access token in Section 4.1 after nit: I'd place the emphasis more on "in the access token" or even "from the AS" rather than "from the client" -- the RS/AS preestablished relationship is what authenticates these values. validation of the token as specified in Section 4.2. The RS MUST set Does Section 4.2 really say much about validation other than "RS MUST verify the validity of the token"? [I-D.ietf-core-object-security]. After that, the RS MUST derive the complete Security Context following section 3.2.1 of [I-D.ietf-core-object-security], and MUST associate this Security Context with the authorization information from the access token. side note: it's sometimes useful as a rhetorical device to have a discussion of the abstract data model the RS uses -- in this case, that it maintains a collection of Security Contexts with associated authorization information, for all the clients that it's currently communicating with, and that the authorization information is policy that's used as input to processing requests from those clients. Otherwise, this text about "MUST associate" can be a bit vague to the reader. The RS then uses this Security Context to verify the request and send responses to C using OSCORE. If OSCORE verification fails, error (nit?) what is "the request"? I don't think we've talked about a specific OSCORE request yet, so this would probably be better if talking about generic incoming requests from a given client. responses are used, as specified in section 8 of [I-D.ietf-core-object-security]. 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. nit: I suggest "MUST respond with an unprotected [...] error message to requests received that correspond to a security context with an expired token" to tie it back to which requests are affected. If the exchange was an update of access rights, i.e. a new Security nit: comma after "i.e.". Context was derived from a client that already had a Security Context in place, the is RECOMMENDED to delete the old Security Context after OSCORE verification and verification of access rights succeed. The RS MUST delete the Security Context if it deletes the access token associated to it. I'm not sure I understand what the workflow is, here -- I assume that the deletion of the old security context occurs after a successful update via the authz-info endpoint (as opposed to some particular OSCORE-protected request), but I don't know what "verification of access rights" could be performed at that time. Aren't access rights mostly tied to a specific operation, or is this just supposed to be a more generic audience/scope check? Section 4.4 The RS MUST follow the procedures defined in section 5.8.2 of [I-D.ietf-ace-oauth-authz]: if an RS receives an OSCORE-protected request from a client, then the RS processes it according to [I-D.ietf-core-object-security]. If OSCORE verification succeeds, and the target resource requires authorization, the RS retrieves the nit(?): is it appropriate to say "requires additional authorization" (over the implicit authorization given to any authenticated client)? I'm not sure if that would be confusing or not. authorization information from the access token associated to the Security Context. The RS then MUST verify that the authorization information covers the resource and the action requested. In the vein of my previous note about an abstract data model, we may not want to be overly prescriptive about "retrieves [...] from the access token". Per-request introspection is allowed, as is caching the authorization information in a non-token local datastore. I'd also consider rephrasing to "MUST verify that the resource and action requested are authorized", since "covers" is perhaps a little vague. The response code MUST be 4.01 (Unauthorized) in case the client has not used the Security Context associated with the access token, or if RS has no valid access token for the client. If RS has an access The causality here seems a bit weird; how would the RS know what token was intended just from an OSCORE request that's using a random or different security context? token for the client but not for the resource that was requested, RS MUST reject the request with a 4.03 (Forbidden). If RS has an access I'd suggest rephrasing this to be in terms of authorization rather than "token for X", perhaps as "if the RS has an access token for the client but no actions are authorized on the target resource" token for the client but it does not cover the action that was requested on the resource, RS MUST reject the request with a 4.05 (Method Not Allowed). Similarly, perhaps "but the requested action is not authorized". Also, don't both of these descriptions have high overlap with Section 5.8.2 of the core framework? Is it necessary to reiterate those behavior specifications? Section 5 Thank you for clearly stating that the OSCORE security contexts between RS/AS and C/AS must be established independently of any of the mechanisms defined in this document, and that the protocols used for the C/RS, C/AS, and RS/AS steps can be selected independently. Furthermore the requesting entity and the AS communicate using OSCORE ([I-D.ietf-core-object-security]) through the introspection endpoint as specified in section 5.7 of [I-D.ietf-ace-oauth-authz] and through the token endpoint as specified in section 5.6 of [I-D.ietf-ace-oauth-authz]. I'm not entirely sure what this sentence is trying to say -- it comes across a little bit as saying that when this document is in use, the indicated interactions also use OSCORE, but that of course can't be what's actually intended. Perhaps just saying that the behavior of the introspection endpoing is specified in section 5.7 of [framework] and that of the token endpoint is specified in section 5.6 of [framework] would suffice? Section 6 o the client receives a number of 4.01 Unauthorized responses to OSCORE requests using the same security context. The exact number needs to be specified by the application. Is this a global counter or does it get reset by a successful OSCORE response? o the client receives a new nonce in the 2.01 (Created) response (see Section 4.2) to a POST request to the authz-info endpoint, when re-posting a non-expired token associated to the existing context. Why is "non-expired" specifically relevant? The RS MUST discard the current security context associated with a client when: o Sequence Number space ends. o Access token associated with the context expires. nit: we should make the grammar of the list elements parallel to the client's list, so "the Sequence Number space ends." and "the access token associated with the context expires". Section 7 We talk about both nonces as needing to be "very unlikely to have been previously used", and it might be worth trying to quantify that (e.g., "chance of inadvertent collision less than 2^-32"). As alluded to in my high-level point, we should have more discussion of the consequences of the authz-info exchange being completely unprotected. a secure binding between the request and the response(s). Thus the basic OSCORE protocol is not intended for use in point-to-multipoint communication (e.g. multicast, publish-subscribe). Implementers of nit: comma after "e.g.". provoke re-use. If that is not guaranteed, nodes are still susceptible to re-using AEAD nonces and keys, in case the Security Context is lost, and on-path attacker replay messages. This text is talking about AEAD nonces, but the nonces (and 64-bit recommendation) previously discussed are the nonces used in the Master Salt (and thus Master Secret) calculation; we don't really talk about AEAD nonces specifically anywhere in the document, other than to point out the risk of (nonce, key) reuse. IIUC, vulnerable nodes would need to reuse both the N1 or N2 values defined in this spec as well as the OSCORE partial IV in order to collide the AEAD (nonce, key) pair (noting that both key and common IV are influenced by the Master Salt). That said, if the N1 generation is flawed it seems quite plausible that PIV generation is similarly flawed, so we are right to document the concern. Also, the grammar here is a little bit weird, so perhaps a rewording to: % provoke re-use. If that is not guaranteed, nodes are % susceptible to re-use of AEAD (nonces, keys) pairs, especially since an on-path % attacker can cause the client to use an arbitrary nonce for Security % Context establishment. Even partial loss of Security Context information % can allow an on-path attacker to replay messages. though I'm not entirely sure I understand which replay scenarios you had in mind. This profiles recommends that the RS maintains a single access token nit: "This profile" singular. Also, tokens may contradict each other which may lead the server to enforce wrong permissions. If one of the access tokens expires Could you give me an example of the contradiction scenarios? I see the "common" case as being roughly "Token T1 gives access to the set X of resources and token T2 gives access to a partially disjoint set Y of resources", but I don't know that such a scenario would be considered a "conflict". To get a conflict I'd expect more like "token T1 indicates that access to X is to be denied, but token T2 indicates that access to X is to be allowed" with some sort of explicit negative ACL, but I don't think OAuth really has a concept of negative ACL. Section 8 There might be a few more privacy considerations worth mentioning: - the token is sent in the clear to the authz-info endpoint, so if a single token is used with multiple audiences or RSes, a client that uses the same token from multiple locations can be tracked/correlated by the access token's value. - the nonces exchanged in the authz-info exchange are also sent in the clear, so using random nonces is best for privacy (as opposed to, e.g., a counter, that might leak some information). - the identifiers clientId/serverId that are created/assigned for this protocol have some privacy considerations; they overlap a lot with the core OSCORE considerations in terms of the potential privacy consequences but there might be a little more to say about guidelines for how the identifiers are generated. If I'm reading OSCORE correctly, for the uses specified in this document only the clientId will actually go on the wire? - similarly, there may be considerations for the ID context values. Section 9.1 o Profile Description: Profile for using OSCORE to secure communication between constrained nodes using the Authentication and Authorization for Constrained Environments framework. This is the registry for ACE profiles; "using the Authentication and Authorization for Constrained Envirornments framework" feels redundant. There's also perhaps something to say about defining "coap_oscore" for all three interaction flows even though the procedures for two of the three are essentially just "out of the scope of this specification", though having *some* identifier for "use OSCORE" is probably still useful. Section 9.2 name The JSON name requested (e.g., "ms"). Because a core goal of this specification is for the resulting representations to be compact, it is RECOMMENDED that the name be short. This name is case sensitive. Names may not match other registered names in a case-insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception. The name is nit: I'd suggest s/state/determine/ CBOR label The value to be used to identify this algorithm. Key map labels MUST be unique. The label can be a positive integer, a nit: s/Key map/Map key/ negative integer or a string. Integer values between 0 and 255 and strings of length 1 are designated as Standards Track Document required. Integer values from 256 to 65535 and strings of length 2 are designated as Specification Required. Integer values of greater than 65535 and strings of length greater than 2 are designated as expert review. Integer values less than -65536 are marked as private use. So use of negative integers from -65535 to -1 and positive integers greater than or equal to 65536 is not defined? I'd also consider listing [I-D.ietf-core-object-security] as an additional reference for the initial entries, since that specifies the actual semantics of the fields in question. Section 9.3 "OSCORE_Security_Context" feels like a somewhat long name in light of the previous commentary about shorter names being preferred. :) o Confirmation Method Description: OSCORE_Security_Context carrying the OSCORE Security Context parameters I'd suggest rewording the description to "parameters for using OSCORE per-message security with implicit key confirmation" Section 9.4 [same suggested rewording] Section 9.5 Thank you for indicating in which direction the various considerations should sway the experts' decisions, as opposed to just what the experts should consider. :) The IANA registry established in this document is defined as expert review. This section gives some general guidelines for what the nit: I suggest "defined to use the Expert Review registration policy". The zones tagged as private use are intended for testing purposes and closed environments, code points in other ranges should not be assigned for testing. nit: comma splice o Specifications are required for the standards track range of point assignment. Specifications should exist for specification required ranges, but early assignment before a specification is available is considered to be permissible. Specifications are side note: this is a little awkward, as RFC 7120 formally does not allow "early allocations" for the "Expert Review" policy, so there is not a formal procedure in place to review and expire early allocations that end up not being needed. It might be worth something to chat with the IANA table about in Vancouver. Section 10.2 We might get some sticklers asking for the terminology references to be made normative, but I'm not concerned about it one way or the other for now. Appendix A Thank you for assembling this in list form for me. Do we expect to keep this content in the final RFC? If we do, we should resynchronize to the current list in Appendix C of the framework :) o how/if the authz-info endpoint is protected: Security protocol above I thought authz-info was fully unprotected, per Section 4.1's "The authz-info endpoint is not protected, nor are the responses from this resource." Thanks, Ben From nobody Tue Jan 7 11:44:42 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A762112010E; Tue, 7 Jan 2020 11:44:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <157842628059.20897.9198890448122052089@ietfa.amsl.com> Date: Tue, 07 Jan 2020 11:44:40 -0800 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oauth-params-10.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 19:44:41 -0000 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 : Additional OAuth Parameters for Authorization in Constrained Environments (ACE) Author : Ludwig Seitz Filename : draft-ietf-ace-oauth-params-10.txt Pages : 13 Date : 2020-01-07 Abstract: This specification defines new parameters for the OAuth 2.0 token and introspection endpoints when used with the framework for authentication and authorization for constrained environments (ACE). These are used to express the proof-of-possession key the client wishes to use, the proof-of-possession key that the Authorization Server has selected, and the key the Resource Server should use to authenticate to the client. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-params/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oauth-params-10 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-params-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-params-10 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/ From nobody Tue Jan 7 11:47:00 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B5812010E; Tue, 7 Jan 2020 11:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTdsxh5XRsGb; Tue, 7 Jan 2020 11:46:52 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F41DF12018B; Tue, 7 Jan 2020 11:46:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1578426364; bh=Tu4xrg6927FnFonXjUdigv1DT4A6PNsgDeGZolzckRk=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=KBHblRtS7Tg8uNV3HNhQzA3AnXvmKNW2DT5swlfBkq6lH/Gi16wOq+cIpghGVnoQ0 00nXr0Hf3Eyq0/e/ScDuL7jkesL3YmQDK8dJQpGs2+ktfELopDZB3NY9HDfaXi9bnm OtpGKvaiqx1J1bPplg6q2of3zyF+wvb0COnmxyn4= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.220] ([84.217.44.37]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MSKu0-1jHTCF3nJY-00SfJP; Tue, 07 Jan 2020 20:46:04 +0100 To: Brian Campbell Cc: Roman Danyliw , oauth-ext-review@ietf.org, Daniel Migault , Jim Schaad , Benjamin Kaduk , "ace@ietf.org" , drafts-lastcall@iana.org References: <4a5177af-a442-f109-f620-0ae91953eb63@gmx.de> From: Ludwig Seitz Message-ID: Date: Tue, 7 Jan 2020 20:45:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:+y1ej5PPFNgHyLD9XcCGDYBr23Yz5XbRNQa+orcsVpogp2qIYdc XZeLq2Vh9ultjmlJHt0fvKpiPRc48Qu9AMKEOyqOHBovczDoBZmHICQco8DVjc+9jT7Nr+N /l5AqnBPChTlyvMIUkhOeqaMXJxmBgRMrIYLliFQlibDUMKKz9Vgjh0piufgONpGgFX72yl ro7GJG0Gm85GwvDoMdg4A== X-UI-Out-Filterresults: notjunk:1;V03:K0:4L8bSqakV0k=:c163neaA1+eSTy4ZBzRSTo 9eVq1Nq4Mp5wDay7ecYt6VfZwJ3llZzdRKJ4NfK81prBVgPsP2zZhPvZ5VI/8Hi0BFHhfOEET xMwN6IAfVGDsQ04gQ0XlgZY1iNGdLzQ06hxNiu7Uqo7HbKgOua68PBVyuIV5/3nCHE6N3uS2i bEqHSncymcSab2YHHzvLAcZAV0RZMRlizpnNC2y4DMro0WgV9hcsGFEt2fzP2gZV/nZ9wWzaN mrpN/3Gm9pWnKXeXphrt2X+uK3IyOnKDEFoy5dtfuKQOzyTMPEQuqExwQ4CMZWcRQS/oQYRWl q5Vd3loshWbolpxc3eadFlyApSr1B0Zpkegnt4nP5qhujWxupw+6y6NhpDS0/+KZ0T1ciBG+6 LMPyR0J1By2lrt3xzpW3r/8YQcYVKKhDr/Gm6emeUvCv1O8KRqkO3YN+rh1IfzKIKDzQsIsIE lGKJoehVFoD4pDzfIa70ZYKpUQxTHykVPR+GAFGx+q1MAahfvI5Cx5ii10tgfCodpEsnH7PtZ CIGWr9Uf0JaKVETDTPQDKKV2N6kRScr3K3I3iWSjUyl2NpGWkikkVKvskrZqsGZRSMUiA689+ VXuZ1NdshPhoPUjNiYTkQ791LbM9Z7saYNt8PFCHS/obhqOtC3ONdizpOSsPR46kXGcLhcdUm OEAROmsT6hlKrCMZrw9s46Sn3ju5ttf5HO+H/24DqJ+y0ApjhLiSTOFa5BULuaXBIxsOeIuAB gK2TxIkg3WddQiRwE0XY0il3s1hyammUY2vACaae7tlZoiTTls2rFCTwYdLzT/NyWgryEnAN5 d3ob94L2038aaosQh/W2Pacl/ryzTwQhKJt/qi+2rc6f/mKB92rVDrkELw4d8WJyOqbBlXr7p kD4jyJyDKMtmQY0TGXOKkKKcOcXgGwzfFdpoQNGeKAUY4Km8kKewYTg0tLQpbi7BXgcq9DN9T 9HMD1wdNhgY5izijW2XoIX4ish3h3MtCHb4peyt1N3ywJ1kzWQIOUnHV13aIiKmImwiDlqV84 VQVH3s7XNZbwF+LGS1MLKCsXfIW942KEbwFw6XfwcymnjoEySW1dmCqnclPDGdC+F3awKF5vF prMOUrKALjc/BaezQ4GF4A/a2O6rOdg5uVkFCetLpJxnRqvmbPN2gbZiOFtIZcBKEGNuOfGCg 0ZhfPxfPupH3BvioazLWYHE0C1ATVVcR+i85VR6pdAQLk8Vk+r802D6InOCjEeTfy7X0kSguL /zreJHJ3Hwyryjk6/f8bruTeicFXZQJqu67kdnqxxc2ZoWWrnipCyMx9QIqg= Archived-At: Subject: Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 19:46:53 -0000 On 2019-12-23 22:32, Brian Campbell wrote: > The OAuth Token Introspection Response registry > > already has an entry for "cnf", which makes the first request in > https://tools.ietf.org/html/draft-ietf-ace-oauth-params-07#section-9.4 > rather problematic. > OAuth beats us on the finish line again :-( I have updated the draft to remove the registration and refer to the MTLS draft. /Ludwig From nobody Tue Jan 7 11:51:44 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F3C12010E; Tue, 7 Jan 2020 11:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InMx8zdpYpmg; Tue, 7 Jan 2020 11:51:41 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E2051200B3; Tue, 7 Jan 2020 11:51:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1578426697; bh=u4FWoyL1FokOFKhNw+wkhzKnyo8QG09ICH6sV+8frOc=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=jxh+uWQNrwxbfAi0qgSQmAjaL1aJHRW0jXA7Aa/2kdyVY54IoRQKYYDb0pIQArpEN glK21NjaX1m26L6DxysGwt4k2CRHsTimKiFgxbAgz4OzuFCxAQqPDoJiLP3uOqE3C7 OaKU2Rf0gRtzyvG1wi/yrtMtpr9NMzgw0O9k1alk= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.220] ([84.217.44.37]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MD9T7-1ixxJR3iy1-009A5e; Tue, 07 Jan 2020 20:51:36 +0100 To: elwynd , gen-art@ietf.org Cc: last-call@ietf.org, draft-ietf-ace-oauth-params.all@ietf.org, ace@ietf.org References: From: Ludwig Seitz Message-ID: <37d7eaf1-b408-f77a-40bc-d3a2a3559db7@gmx.de> Date: Tue, 7 Jan 2020 20:51:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:Ug1ethg04MxXI+y0u5WCetYTcq6PGrgZnNyELDBwZIwj7naXMSq 8MF4prodGDIYVUkjvii7Z7c3AtHbXeZ4s4tPe1BTn/EndrbFZePlk3er4J+tIpVSzOcQ++5 +HZXWvC1S0zBAJmd5sK/mNqHvkeLuym+RUC0SdSo6z3w/mid1UXs6hcoUCOcKU0tv5YexNq ixC0dWU/r2dd75pZ59BEQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:uWlTJtEtqfs=:1B+Pie11Aasyd+HLjxMKaC M/WZs/Vayb5vWPIbk64Lm6pXMeuHaY7Zk++nQKQJdDqA8rG3n3EE4yG3dqxD/QLHUlOUZdIcc cCfJaL1obUycFDyOw91c5VGEbtUYEuQNFtiztsNC+vZIPygAM8+Jz42CruGmZOa82hS1v/yZw W6l280JwhEY6e7xAsuyggv5UupXcD6tFK+Ezw4xGkj3BCAJu1bgk6wHleKQvrHRhMPj9ViqyU N1tF8r+UiA7i1L6sMXXNdZmU2mr2tQgnYkJSPSyBrSkLshaOD7liJ+8k435hajmFoxfS6I4W7 mbFIW7GKKfbu23CO+mHDuIZBXux7sw2qUSdeA5Bt9i2jaG35lm9NluWqTyjl6iBGfjki/Ft7g v+d9qxGfkAz/JDWH+wjpaU5MOJXoC0U5SpvAIq0NgjvwWmDXW6HULOZRnj5M5/I6CzrhgOYm2 PCmaotL2+tOuOIz16pUWxuuJhS/IM5sj93rJh+MdEeDhCS42B/wY66uzxoqWnmdMmvZuSwQM1 SgsuLt/tjVMqnsHKqBJg0Kb0bQ93PNZD7JWrMRihHaTGaadWfT2Wh/l/cQuPN1FTrr2kLoqld s6ZDAs9umbMH6/uPyBaFpZFDA3bV8od1SNcf2kNGAqgpDWWTZwl9o33z+irQR+Bkr9oPdXPzT pP147HX6ryDV0Cldtul1W89xUA8LCcbyzUHo1ysCH3U6bHNuWdG6UqWzv+QTNSetLZlt9vinV T/0+OapPflZUueCIzCR3RLFaC+ejxXEXYU1kBFTFaGHntQKSUr7EOvY0mDZbZSUfxKPumtrk/ /ML0porupset4QaysLUR3jD4LyERY6F8ZgKMpxj8vBzqgwGoTS/g5/PJ2kcnwMDdu/FkWlwqK bSyOqbi7fiSGbGI9Vb67FtxYZ/5779WwA3OJ/1Uler/HvbQUdRB5zaz2xleT+RUpTQXuGvXrF HCgaegTF3jxfO6lxEazKQe/u9T4O/F8xam19AmUFj67l7DQRco9mVYPw+JIp9RVZ36IjFgdeL qivHLadS2SKd+gOf5MzRaV1BZzPGNj1W6TKM39yfZBuV5dS4nrFsoPjQYI6wEEi/GFjQPT1sd /i/lPQKBzKF3GBOFr8fW1lNThvxjyHS+xnDPgcbW9BEuJcmRNdg5VgMJAj7sIwDLsn7wzl3oG gOBwY5wqfihy06EzwCaicJjW/XFcu81GgBC5m0XCo8y3uerjhCLRyRxiUQb337Mk1YC8sHr4q NGbyGsdCVj/tUt3ImcTK6MTgsd1Yv0eoAXkxpArFPNWVzWl//Pb89p6MIRV0= Archived-At: Subject: Re: [Ace] [Gen-art] Genart last call review of draft-ietf-ace-oauth-params-06 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 19:51:43 -0000 On 2019-12-22 19:27, elwynd wrote: > Hi, Ludwig. > > Having had another look at section 3.1 of > draft-ietf-ace-cwt-proof-of-possession, technically the rules about > which keys have to be present are not part of the syntax of the cnf > claim.=C2=A0 The point can be covered by changing '"syntax of the 'cnf' = claim" > to "syntax and semantics of the 'cnf' claim" > in each case. > > However, the second look threw up another point:=C2=A0 Figure 2 in s3.2 = gives > a Symetric key example=C2=A0 - I think this should use an Encrypted_COSE= _Key > (or Encrypted_COSE_Key0) as described in section 3.3 of > draft-ietf-ace-cwt-proof-of-possession. > > Otherwise I think we are done. > > Eventually we will get to Christmas! > > Cheers, > Elwyn > > Hello Elwyn, I hope you had a merry Christmas and a happy new year's eve. I have updated the draft to -10, fixing the phrasing to your suggestion from the first paragraph above in various places (and an issue that came up during IANA review). Given my argument for not having the encrypted COSE_Key in figure 2 I left that part as it was. Please indicate whether this is acceptable with the given explanation. Regards, Ludwig From nobody Tue Jan 7 12:17:09 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2CA120077; Tue, 7 Jan 2020 12:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RXT9wuLycYN; Tue, 7 Jan 2020 12:17:01 -0800 (PST) Received: from weald.air.saab.se (weald.air.saab.se [136.163.212.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D843E12010C; Tue, 7 Jan 2020 12:17:00 -0800 (PST) Received: from mailhub1.air.saab.se ([136.163.213.4]) by weald.air.saab.se (8.14.4/8.14.4) with ESMTP id 007KGw1a030920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 7 Jan 2020 21:16:58 +0100 Received: from corpappl16596.corp.saab.se (corpappl16596.corp.saab.se [10.12.12.128]) by mailhub1.air.saab.se (8.13.8/8.13.8) with ESMTP id 007KGiTD024527 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Jan 2020 21:16:44 +0100 Received: from corpappl16595.corp.saab.se (10.12.12.127) by corpappl16596.corp.saab.se (10.12.12.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Tue, 7 Jan 2020 21:16:44 +0100 Received: from corpappl16595.corp.saab.se ([fe80::3c3e:6470:4c56:a86f]) by corpappl16595.corp.saab.se ([fe80::3c3e:6470:4c56:a86f%4]) with mapi id 15.01.1847.003; Tue, 7 Jan 2020 21:16:44 +0100 From: Seitz Ludwig To: Charlie Kaufman CC: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-ace-oauth-params.all@ietf.org" , "ace@ietf.org" Thread-Topic: Secdir review of draft-ietf-ace-oauth-params-06 Thread-Index: AQHVtSWsVML0EqYNLk+qsAH30Mo1kKffwt9Q Date: Tue, 7 Jan 2020 20:16:44 +0000 Message-ID: <2a0e711297c642b49413d7d749e619b4@combitech.se> References: <20191217220157.GH81833@kduck.mit.edu> In-Reply-To: <20191217220157.GH81833@kduck.mit.edu> Accept-Language: en-SE, sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.13.198] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Saab-MailScanner-Information: Please contact the ISP for more information X-Saab-MailScanner-ID: 007KGiTD024527 X-Saab-MailScanner: Found to be clean X-Saab-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.498, required 5, ALL_TRUSTED -1.00, KAM_NUMSUBJECT 0.50, SURBL_BLOCKED 0.00, URIBL_BLOCKED 0.00) X-Saab-MailScanner-From: ludwig.seitz@combitech.se X-Saab-MailScanner-Watermark: 1579033004.95031@Rqw2G2HARVI185TIGoWbSw X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (weald.air.saab.se [136.163.212.3]); Tue, 07 Jan 2020 21:16:58 +0100 (CET) Archived-At: Subject: Re: [Ace] Secdir review of draft-ietf-ace-oauth-params-06 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 20:17:09 -0000 Hello Charlie, Thank you for the review, sorry for the tardive reply (things got a bit cha= otic due to an affiliation change on my part). The -10 version here: https:= //datatracker.ietf.org/doc/draft-ietf-ace-oauth-params addresses your comme= nts given the additional explanations by Ben. Please confirm if this satisfies your requested changes. Regards, Ludwig -----Original Message----- From: Benjamin Kaduk =20 Sent: den 17 december 2019 23:02 To: Charlie Kaufman Cc: secdir@ietf.org; iesg@ietf.org; draft-ietf-ace-oauth-params.all@ietf.or= g Subject: Re: Secdir review of draft-ietf-ace-oauth-params-06 Hi Charlie, Thanks for the review! On Fri, Dec 13, 2019 at 07:48:22AM +0000, Charlie Kaufman wrote: > I have reviewed this document as part of the security directorate's ongoi= ng effort to review all IETF documents being processed by the IESG. These = comments were written primarily for the benefit of the security area direct= ors. Document editors and WG chairs should treat these comments just like = any other last call comments. >=20 > This document only exists because of a scheduling issue between the ACE a= nd OAUTH working groups. The ACE working group needed some additional OAUTH= extensions added more quickly that the OAUTH group could manage to do it. = This document is intended to only exist until the OAUTH group can make the = corresponding changes. As such, it really doesn't have security considerati= ons beyond those in the document it modifies. >=20 > The security considerations section says (and I agree): >=20 > This document is an extension to [I-D.ietf-ace-oauth-authz]. All security= considerations from that document apply here as well. >=20 > Some acronyms that were not defined (but this might be OK in the=20 > context of this being a modification to another document): AS, RS,=20 > CoAP, cnf, CBOR, pop, CWT >=20 >=20 > A few typos / odd phrasing: >=20 > Abstract: whishes -> wishes > Appendix A: possesion -> possession >=20 > >From Section 2: > Note that the term "endpoint" is used here following its OAuth 2.0 [RFC67= 49] definition, which is to denote resources such as token and introspectio= n at the AS and authz-info at the RS. >=20 > Really? The term "endpoint" refers to tokens and authz-info data structur= es? This seems unlikely. Not data structures, but (HTTP/CoAP) resources -- "things you can POST to". > Continuing in Section 2: > The CoAP [RFC7252] definition, which is "An entity participating in the C= oAP protocol" is not used in this specification. >=20 > Why is a definition that does not apply relevant to this document? This document is at the intersection of two worlds: CoAP and OAuth. Both d= efine "endpoint" but in contradictory ways. Since at least one has to lose= , giving the reader a pretty explicit hint that they're wrong to use a give= n definition seems to have value. But maybe I'm in the rough; we'll see :) -Ben From nobody Tue Jan 7 20:01:31 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A17120041; Tue, 7 Jan 2020 20:01:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ace-chairs@ietf.org, kaduk@mit.edu, mglt.ietf@gmail.com, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157845608938.21005.6266592271915878964.idtracker@ietfa.amsl.com> Date: Tue, 07 Jan 2020 20:01:29 -0800 Archived-At: Subject: [Ace] ace - Update to a Meeting Session Request for IETF 107 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 04:01:29 -0000 An update to a meeting session request has just been submitted by Daniel Migault, a Chair of the ace working group. --------------------------------------------------------- Working Group Name: Authentication and Authorization for Constrained Environments Area Name: Security Area Session Requester: Daniel Migault Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 30 Conflicts to Avoid: Chair Conflict: cbor calext tmrid Technology Overlap: teep lake tls oauth t2trg suit core cose Key Participant Conflict: secdispatch saag ipsecme acme cfrg lwig emu homenet lamps dnsop abcd People who must be present: Daniel Migault Jim Schaad Benjamin Kaduk Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Jan 7 20:04:49 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E863120041; Tue, 7 Jan 2020 20:04:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ace-chairs@ietf.org, kaduk@mit.edu, mglt.ietf@gmail.com, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157845628708.21019.5622826052377360629.idtracker@ietfa.amsl.com> Date: Tue, 07 Jan 2020 20:04:47 -0800 Archived-At: Subject: [Ace] ace - Update to a Meeting Session Request for IETF 107 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 04:04:47 -0000 An update to a meeting session request has just been submitted by Daniel Migault, a Chair of the ace working group. --------------------------------------------------------- Working Group Name: Authentication and Authorization for Constrained Environments Area Name: Security Area Session Requester: Daniel Migault Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 30 Conflicts to Avoid: Chair Conflict: tmrid calext cbor Technology Overlap: teep lake tls oauth t2trg suit core cose Key Participant Conflict: abcd dnsop lamps homenet emu lwig cfrg ipsecme saag secdispatch People who must be present: Daniel Migault Jim Schaad Benjamin Kaduk Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Jan 8 05:33:53 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8AA1200F1; Wed, 8 Jan 2020 05:33:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ace-chairs@ietf.org, kaduk@mit.edu, mglt.ietf@gmail.com, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157849042989.22563.18287344486537892844.idtracker@ietfa.amsl.com> Date: Wed, 08 Jan 2020 05:33:49 -0800 Archived-At: Subject: [Ace] ace - Update to a Meeting Session Request for IETF 107 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 13:33:50 -0000 An update to a meeting session request has just been submitted by Daniel Migault, a Chair of the ace working group. --------------------------------------------------------- Working Group Name: Authentication and Authorization for Constrained Environments Area Name: Security Area Session Requester: Daniel Migault Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 30 Conflicts to Avoid: Chair Conflict: tmrid calext cbor lamps Technology Overlap: teep lake tls oauth t2trg suit core cose Key Participant Conflict: abcd dnsop homenet emu lwig cfrg ipsecme saag secdispatch People who must be present: Daniel Migault Jim Schaad Benjamin Kaduk Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Jan 8 05:47:30 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D2B1200F6; Wed, 8 Jan 2020 05:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWdvF26EgJ40; Wed, 8 Jan 2020 05:47:26 -0800 (PST) Received: from a-painless.mh.aa.net.uk (a-painless.mh.aa.net.uk [IPv6:2001:8b0:0:30::51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94F8C1200C5; Wed, 8 Jan 2020 05:47:26 -0800 (PST) Received: from 7.5.e.9.2.3.d.7.0.b.e.4.1.1.4.7.1.0.0.0.f.b.0.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:bf:1:7411:4eb0:7d32:9e57]) by a-painless.mh.aa.net.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ipBJe-0005o0-Al; Wed, 08 Jan 2020 13:24:06 +0000 SavedFromEmail: elwynd@folly.org.uk Date: Wed, 08 Jan 2020 13:23:59 +0000 In-Reply-To: <37d7eaf1-b408-f77a-40bc-d3a2a3559db7@gmx.de> Importance: normal From: elwynd To: Ludwig Seitz , gen-art@ietf.org Cc: last-call@ietf.org, draft-ietf-ace-oauth-params.all@ietf.org, ace@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_15289106259012960" Message-ID: Archived-At: Subject: Re: [Ace] [Gen-art] Genart last call review of draft-ietf-ace-oauth-params-06 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 13:47:29 -0000 ----_com.samsung.android.email_15289106259012960 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 U2VudCBmcm9tIFNhbXN1bmcgdGFibGV0LgotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0t LS0tRnJvbTogTHVkd2lnIFNlaXR6IDxsdWR3aWdfc2VpdHpAZ214LmRlPiBEYXRlOiAwNy8wMS8y MDIwICAxOTo1MiAgKEdNVCswMDowMCkgVG86IGVsd3luZCA8ZWx3eW5kQGZvbGx5Lm9yZy51az4s IGdlbi1hcnRAaWV0Zi5vcmcgQ2M6IGxhc3QtY2FsbEBpZXRmLm9yZywgZHJhZnQtaWV0Zi1hY2Ut b2F1dGgtcGFyYW1zLmFsbEBpZXRmLm9yZywgYWNlQGlldGYub3JnIFN1YmplY3Q6IFJlOiBbR2Vu LWFydF0gW0FjZV0gR2VuYXJ0IGxhc3QgY2FsbCByZXZpZXcgb2YKwqAgZHJhZnQtaWV0Zi1hY2Ut b2F1dGgtcGFyYW1zLTA2IE9uIDIwMTktMTItMjIgMTk6MjcsIGVsd3luZCB3cm90ZTo+IEhpLCBM dWR3aWcuPj4gSGF2aW5nIGhhZCBhbm90aGVyIGxvb2sgYXQgc2VjdGlvbiAzLjEgb2Y+IGRyYWZ0 LWlldGYtYWNlLWN3dC1wcm9vZi1vZi1wb3NzZXNzaW9uLCB0ZWNobmljYWxseSB0aGUgcnVsZXMg YWJvdXQ+IHdoaWNoIGtleXMgaGF2ZSB0byBiZSBwcmVzZW50IGFyZSBub3QgcGFydCBvZiB0aGUg c3ludGF4IG9mIHRoZSBjbmY+IGNsYWltLsKgIFRoZSBwb2ludCBjYW4gYmUgY292ZXJlZCBieSBj aGFuZ2luZyAnInN5bnRheCBvZiB0aGUgJ2NuZicgY2xhaW0iPiB0byAic3ludGF4IGFuZCBzZW1h bnRpY3Mgb2YgdGhlICdjbmYnIGNsYWltIj4gaW4gZWFjaCBjYXNlLj4+IEhvd2V2ZXIsIHRoZSBz ZWNvbmQgbG9vayB0aHJldyB1cCBhbm90aGVyIHBvaW50OsKgIEZpZ3VyZSAyIGluIHMzLjIgZ2l2 ZXM+IGEgU3ltZXRyaWMga2V5IGV4YW1wbGXCoCAtIEkgdGhpbmsgdGhpcyBzaG91bGQgdXNlIGFu IEVuY3J5cHRlZF9DT1NFX0tleT4gKG9yIEVuY3J5cHRlZF9DT1NFX0tleTApIGFzIGRlc2NyaWJl ZCBpbiBzZWN0aW9uIDMuMyBvZj4gZHJhZnQtaWV0Zi1hY2UtY3d0LXByb29mLW9mLXBvc3Nlc3Np b24uPj4gT3RoZXJ3aXNlIEkgdGhpbmsgd2UgYXJlIGRvbmUuPj4gRXZlbnR1YWxseSB3ZSB3aWxs IGdldCB0byBDaHJpc3RtYXMhPj4gQ2hlZXJzLD4gRWx3eW4+PkhlbGxvIEVsd3luLEkgaG9wZSB5 b3UgaGFkIGEgbWVycnkgQ2hyaXN0bWFzIGFuZCBhIGhhcHB5IG5ldyB5ZWFyJ3MgZXZlLkkgaGF2 ZSB1cGRhdGVkIHRoZSBkcmFmdCB0byAtMTAsIGZpeGluZyB0aGUgcGhyYXNpbmcgdG8geW91ciBz dWdnZXN0aW9uZnJvbSB0aGUgZmlyc3QgcGFyYWdyYXBoIGFib3ZlIGluIHZhcmlvdXMgcGxhY2Vz IChhbmQgYW4gaXNzdWUgdGhhdCBjYW1ldXAgZHVyaW5nIElBTkEgcmV2aWV3KS5HaXZlbiBteSBh cmd1bWVudCBmb3Igbm90IGhhdmluZyB0aGUgZW5jcnlwdGVkIENPU0VfS2V5IGluIGZpZ3VyZSAy IElsZWZ0IHRoYXQgcGFydCBhcyBpdCB3YXMuIFBsZWFzZSBpbmRpY2F0ZSB3aGV0aGVyIHRoaXMg aXMgYWNjZXB0YWJsZXdpdGggdGhlIGdpdmVuIGV4cGxhbmF0aW9uLlJlZ2FyZHMsTHVkd2lnSGks IEx1ZHdpZy5ZZXMsIHdlIGhhZCBhIHBsZWFzYW50IGZlc3RpdmUgc2Vhc29uIC0gSG9wZSB5b3Vy cyB3YXMgZ29vZCBhbHNvLlRoZSAtMTAgZHJhZnQgbG9va3MgZ29vZC7CoCBSZWdhcmRpbmcgdGhl IHN5bW1ldHJpYyBrZXkgaW4gczMuIDIvRmlndXJlIDIsIEkgdGhpbmsgaXQgd291bGQgYmUgd29y dGggYWRkaW5nIGEgc2VudGVuY2UgdG8gcG9pbnQgb3V0IHRoYXQgb25lIG1pZ2h0IGhhdmUgdG8g dXNlIHRoZSBlbmNyeXB0ZWQgZm9ybSBwZXIgcHJvb2Ytb2YtcG9zZXNzaW9uIGRyYWZ0IGlmIHRo ZSBvdmVyYWxsIG1lc3NhZ2Ugd2FzIG5vdCBlbmNyeXB0ZWQgKGFzIGluIGl0IGlzIGluIHRoZSBv YXV0aCB1c2FnZSkuQ2hlZXJzLEVsd3lu ----_com.samsung.android.email_15289106259012960 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXYgZGlyPSJh dXRvIj48YnI+PC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0byI+ PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRpdiBpZD0iY29tcG9zZXJfc2ln bmF0dXJlIiBkaXI9ImF1dG8iPjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTo4NSU7Y29sb3I6IzU3NTc1 NyIgZGlyPSJhdXRvIj5TZW50IGZyb20gU2Ftc3VuZyB0YWJsZXQuPC9kaXY+PC9kaXY+PGRpdiBk aXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6 MTAwJTtjb2xvcjojMDAwMDAwIiBkaXI9ImF1dG8iPjwhLS0gb3JpZ2luYWxNZXNzYWdlIC0tPjxk aXY+LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLTwvZGl2PjxkaXY+RnJvbTogTHVk d2lnIFNlaXR6ICZsdDtsdWR3aWdfc2VpdHpAZ214LmRlJmd0OyA8L2Rpdj48ZGl2PkRhdGU6IDA3 LzAxLzIwMjAgIDE5OjUyICAoR01UKzAwOjAwKSA8L2Rpdj48ZGl2PlRvOiBlbHd5bmQgJmx0O2Vs d3luZEBmb2xseS5vcmcudWsmZ3Q7LCBnZW4tYXJ0QGlldGYub3JnIDwvZGl2PjxkaXY+Q2M6IGxh c3QtY2FsbEBpZXRmLm9yZywgZHJhZnQtaWV0Zi1hY2Utb2F1dGgtcGFyYW1zLmFsbEBpZXRmLm9y ZywgYWNlQGlldGYub3JnIDwvZGl2PjxkaXY+U3ViamVjdDogUmU6IFtHZW4tYXJ0XSBbQWNlXSBH ZW5hcnQgbGFzdCBjYWxsIHJldmlldyBvZgombmJzcDsgZHJhZnQtaWV0Zi1hY2Utb2F1dGgtcGFy YW1zLTA2IDwvZGl2PjxkaXY+PGJyPjwvZGl2PjwvZGl2Pk9uIDIwMTktMTItMjIgMTk6MjcsIGVs d3luZCB3cm90ZTo8YnIgZGlyPSJhdXRvIj4mZ3Q7IEhpLCBMdWR3aWcuPGJyIGRpcj0iYXV0byI+ Jmd0OzxiciBkaXI9ImF1dG8iPiZndDsgSGF2aW5nIGhhZCBhbm90aGVyIGxvb2sgYXQgc2VjdGlv biAzLjEgb2Y8YnIgZGlyPSJhdXRvIj4mZ3Q7IGRyYWZ0LWlldGYtYWNlLWN3dC1wcm9vZi1vZi1w b3NzZXNzaW9uLCB0ZWNobmljYWxseSB0aGUgcnVsZXMgYWJvdXQ8YnIgZGlyPSJhdXRvIj4mZ3Q7 IHdoaWNoIGtleXMgaGF2ZSB0byBiZSBwcmVzZW50IGFyZSBub3QgcGFydCBvZiB0aGUgc3ludGF4 IG9mIHRoZSBjbmY8YnIgZGlyPSJhdXRvIj4mZ3Q7IGNsYWltLiZuYnNwOyBUaGUgcG9pbnQgY2Fu IGJlIGNvdmVyZWQgYnkgY2hhbmdpbmcgJyJzeW50YXggb2YgdGhlICdjbmYnIGNsYWltIjxiciBk aXI9ImF1dG8iPiZndDsgdG8gInN5bnRheCBhbmQgc2VtYW50aWNzIG9mIHRoZSAnY25mJyBjbGFp bSI8YnIgZGlyPSJhdXRvIj4mZ3Q7IGluIGVhY2ggY2FzZS48YnIgZGlyPSJhdXRvIj4mZ3Q7PGJy IGRpcj0iYXV0byI+Jmd0OyBIb3dldmVyLCB0aGUgc2Vjb25kIGxvb2sgdGhyZXcgdXAgYW5vdGhl ciBwb2ludDombmJzcDsgRmlndXJlIDIgaW4gczMuMiBnaXZlczxiciBkaXI9ImF1dG8iPiZndDsg YSBTeW1ldHJpYyBrZXkgZXhhbXBsZSZuYnNwOyAtIEkgdGhpbmsgdGhpcyBzaG91bGQgdXNlIGFu IEVuY3J5cHRlZF9DT1NFX0tleTxiciBkaXI9ImF1dG8iPiZndDsgKG9yIEVuY3J5cHRlZF9DT1NF X0tleTApIGFzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDMuMyBvZjxiciBkaXI9ImF1dG8iPiZndDsg ZHJhZnQtaWV0Zi1hY2UtY3d0LXByb29mLW9mLXBvc3Nlc3Npb24uPGJyIGRpcj0iYXV0byI+Jmd0 OzxiciBkaXI9ImF1dG8iPiZndDsgT3RoZXJ3aXNlIEkgdGhpbmsgd2UgYXJlIGRvbmUuPGJyIGRp cj0iYXV0byI+Jmd0OzxiciBkaXI9ImF1dG8iPiZndDsgRXZlbnR1YWxseSB3ZSB3aWxsIGdldCB0 byBDaHJpc3RtYXMhPGJyIGRpcj0iYXV0byI+Jmd0OzxiciBkaXI9ImF1dG8iPiZndDsgQ2hlZXJz LDxiciBkaXI9ImF1dG8iPiZndDsgRWx3eW48YnIgZGlyPSJhdXRvIj4mZ3Q7PGJyIGRpcj0iYXV0 byI+Jmd0OzxiciBkaXI9ImF1dG8iPjxiciBkaXI9ImF1dG8iPkhlbGxvIEVsd3luLDxiciBkaXI9 ImF1dG8iPjxiciBkaXI9ImF1dG8iPkkgaG9wZSB5b3UgaGFkIGEgbWVycnkgQ2hyaXN0bWFzIGFu ZCBhIGhhcHB5IG5ldyB5ZWFyJ3MgZXZlLjxiciBkaXI9ImF1dG8iPjxiciBkaXI9ImF1dG8iPkkg aGF2ZSB1cGRhdGVkIHRoZSBkcmFmdCB0byAtMTAsIGZpeGluZyB0aGUgcGhyYXNpbmcgdG8geW91 ciBzdWdnZXN0aW9uPGJyIGRpcj0iYXV0byI+ZnJvbSB0aGUgZmlyc3QgcGFyYWdyYXBoIGFib3Zl IGluIHZhcmlvdXMgcGxhY2VzIChhbmQgYW4gaXNzdWUgdGhhdCBjYW1lPGJyIGRpcj0iYXV0byI+ dXAgZHVyaW5nIElBTkEgcmV2aWV3KS48YnIgZGlyPSJhdXRvIj48YnIgZGlyPSJhdXRvIj5HaXZl biBteSBhcmd1bWVudCBmb3Igbm90IGhhdmluZyB0aGUgZW5jcnlwdGVkIENPU0VfS2V5IGluIGZp Z3VyZSAyIEk8YnIgZGlyPSJhdXRvIj5sZWZ0IHRoYXQgcGFydCBhcyBpdCB3YXMuIFBsZWFzZSBp bmRpY2F0ZSB3aGV0aGVyIHRoaXMgaXMgYWNjZXB0YWJsZTxiciBkaXI9ImF1dG8iPndpdGggdGhl IGdpdmVuIGV4cGxhbmF0aW9uLjxiciBkaXI9ImF1dG8iPjxiciBkaXI9ImF1dG8iPlJlZ2FyZHMs PGJyIGRpcj0iYXV0byI+PGJyIGRpcj0iYXV0byI+THVkd2lnPGJyIGRpcj0iYXV0byI+PGRpdiBk aXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0byI+SGksIEx1ZHdpZy48L2Rpdj48ZGl2 IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5ZZXMsIHdlIGhhZCBhIHBsZWFz YW50IGZlc3RpdmUgc2Vhc29uIC0gSG9wZSB5b3VycyB3YXMgZ29vZCBhbHNvLjwvZGl2PjxkaXYg ZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRpdiBkaXI9ImF1dG8iPlRoZSAtMTAgZHJhZnQgbG9va3Mg Z29vZC4mbmJzcDsgUmVnYXJkaW5nIHRoZSBzeW1tZXRyaWMga2V5IGluIHMzLiAyL0ZpZ3VyZSAy LCBJIHRoaW5rIGl0IHdvdWxkIGJlIHdvcnRoIGFkZGluZyBhIHNlbnRlbmNlIHRvIHBvaW50IG91 dCB0aGF0IG9uZSBtaWdodCBoYXZlIHRvIHVzZSB0aGUgZW5jcnlwdGVkIGZvcm0gcGVyIHByb29m LW9mLXBvc2Vzc2lvbiBkcmFmdCBpZiB0aGUgb3ZlcmFsbCBtZXNzYWdlIHdhcyBub3QgZW5jcnlw dGVkIChhcyBpbiBpdCBpcyBpbiB0aGUgb2F1dGggdXNhZ2UpLjwvZGl2PjxkaXYgZGlyPSJhdXRv Ij48YnI+PC9kaXY+PGRpdiBkaXI9ImF1dG8iPkNoZWVycyw8L2Rpdj48ZGl2IGRpcj0iYXV0byI+ RWx3eW48L2Rpdj48L2JvZHk+PC9odG1sPg== ----_com.samsung.android.email_15289106259012960-- From nobody Wed Jan 8 07:06:41 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0B3120115; Wed, 8 Jan 2020 07:06:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157849599890.22535.10849141664157127228@ietfa.amsl.com> Date: Wed, 08 Jan 2020 07:06:38 -0800 Archived-At: Subject: [Ace] Authentication and Authorization for Constrained Environments (ace) WG Virtual Meeting: 2020-01-31 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 15:06:39 -0000 The Authentication and Authorization for Constrained Environments (ace) Working Group will hold a virtual interim meeting on 2020-01-31 from 11:00 to 12:30 America/New_York. Agenda: * chairs slides (note well, agenda bashing ...) * draft-ietf-ace-key-groupcomm * draft-ietf-ace-key-groupcomm-oscore * draft-ietf-ace-mqtt-tls-profile * draft-ietf-ace-coap-pubsub-profile * AOB Information about remote participation: ACE Working Group invites you to join this Webex meeting. Meeting number (access code): 641 066 992 Meeting password: akZaYmff Friday, January 31, 2020 11:00 am | (UTC-05:00) Eastern Time (US & Canada) | 1 hr 30 mins Join meeting Join by phone Tap to call in from a mobile device (attendees only) 1-650-479-3208 Call-in toll number (US/Canada) Join from a video system or application Dial 641066992@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. Join using Microsoft Lync or Microsoft Skype for Business Dial 641066992.ietf@lync.webex.com Need help? Go to http://help.webex.com From nobody Wed Jan 8 08:07:56 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36FC01200B5; Wed, 8 Jan 2020 08:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0uDHSLE5C4J; Wed, 8 Jan 2020 08:07:48 -0800 (PST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2071.outbound.protection.outlook.com [40.107.20.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EBD8120867; Wed, 8 Jan 2020 08:07:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gMROtiRlhMx9zPbjunSFcrshmF6scHYIFxVXLWCUeILm0r96pLv7xqsBC2NqJlZQhvwi8LHRzGm3udOdPZK4BPulc3C/fd7EBaWkD3vffB0rjXKqNU+f4SZmRRLJj7omslZFKsfHcVyFMEycy1VVAh1juyoFocL8pd6kzzaTmb2GsYebkFbgeXfzK4FNlAK+7DNOCk3cScBDZYDrkkPW9SyOKKFNPwSG9j+CeJMmsZdCjQLlWUOkqOMNwvjxrCMj0DBve87qtFXvB3uCTp5ezC+QoVVzKR0erw2uZqbBdrFMzPNk+K+RoRkPjLYNHtNlAt0ZVEI9FMpmFMr7IomTyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=m3mJqFbPtDzESYLm7y08jI8ByO8hjp+4Nel4V5zgWig=; b=CPC16zp3EYE6U1RfdDP5JPEK58OR0qMI6nFJznclPBVinB41zCv5xmapb7xkY+xw0J6JMk63m7NXilR9oZRIhCoTEObDKB+V/g4Npjh5DbRBZkS1gNPshFU8NUwSel1uAdI24zUPIIJ7Zk9r6DCnREPEHgNM1o4FxdrRIDgKARu35wpVYGWnPp67Nerl3GhLr1ZHG4gWq7JMiFW5ym/wQxRiAIkWhCxqbh1HK010dyu+05gmKAeWmoCNVtLw73TOYSwOLQIcoEXPhzAYFfkvOU+RcQA1XzxPSJ43OKzyINNYcLJOtbEolwoAB70TCj+1G8SDxGaRBthg05GIEhSeBg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=m3mJqFbPtDzESYLm7y08jI8ByO8hjp+4Nel4V5zgWig=; b=ViohZ7ozP45JDWN1+PBf7oH7ofca178wsfhCY4qv6eLHKVQDVH1pCidG13LvMAGa/6sxw48HrModTbnMJJBTCRjwnrLm5tzbnIvBw0cy5rycH4r4LBikFqk9Ay/6gBwGt6395oGHpqu/T9lOz7C7B8aUGCGnIM/0TZFV6tlI/y0= Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (10.165.195.159) by VI1P189MB0285.EURP189.PROD.OUTLOOK.COM (10.165.198.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Wed, 8 Jan 2020 16:07:42 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::3485:ce83:891b:469]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::3485:ce83:891b:469%4]) with mapi id 15.20.2623.008; Wed, 8 Jan 2020 16:07:42 +0000 Received: from [10.8.2.14] (196.240.54.60) by HE1PR05CA0312.eurprd05.prod.outlook.com (2603:10a6:7:93::43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9 via Frontend Transport; Wed, 8 Jan 2020 16:07:42 +0000 From: Marco Tiloca To: Jim Schaad , "draft-tiloca-ace-oscore-gm-admin@ietf.org" CC: "ace@ietf.org" Thread-Topic: remarks on draft-tiloca-ace-oscore-gm-admin-00 Thread-Index: AdWfJkCd54YEkIoYSoqR2Q9ieECPkwnF3wsA Date: Wed, 8 Jan 2020 16:07:42 +0000 Message-ID: References: <01b401d59f2e$ff406560$fdc13020$@augustcellars.com> In-Reply-To: <01b401d59f2e$ff406560$fdc13020$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-clientproxiedby: HE1PR05CA0312.eurprd05.prod.outlook.com (2603:10a6:7:93::43) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) authentication-results: spf=none (sender IP is ) smtp.mailfrom=marco.tiloca@ri.se; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [196.240.54.60] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 780f0547-62b6-45ed-166e-08d79454e445 x-ms-traffictypediagnostic: VI1P189MB0285: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3383; x-forefront-prvs: 02760F0D1C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(346002)(136003)(39860400002)(396003)(51444003)(189003)(199004)(4326008)(966005)(81166006)(8676002)(52116002)(81156014)(6486002)(71200400001)(53546011)(36756003)(478600001)(186003)(64756008)(956004)(2616005)(66556008)(16526019)(26005)(66476007)(66616009)(44832011)(66446008)(316002)(2906002)(86362001)(66946007)(4001150100001)(66574012)(31696002)(110136005)(5001810100001)(31686004)(5660300002)(8936002)(16576012); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P189MB0285; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ri.se does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Lsha2dsrQ9x6xIQ0cjQ9S9dvE2y2xCqSsEavpfRAWcyfDS2E3xfAo8TVV+uCkq4TOe3PL/k2bYJoRwwGkAmIZqL566oX/vEvvlaa416lISyl1qLcyt2lX6+ClnlNYeJp23oqCsEIGRxZT5Dj4TjnexGl50dTRxEU6c1eZgYUTem6s6W+VHzxsD0D5qDrX5q3hVUVv56Lor29yR+XllSjJcz0I6xNk9VUO9s299uC3/PUZj1Sgn0jGehi3ZU1+T6ly+yFEZndan2YwbYpgQrTo6Ym9tWlDK4Hs2hLL6BY/wyI1IjHEs8b2ZvQ4k1jeadJQUtYRcmtPcfal8i77JrRsRaJRnAbel6rR7ByBhfz9pznE9yj2BbK1AMB2XnvyYynY091lywxU8GeVS/+Kq23+Fn/9Z+Qpzye6Di0lToLCZ97wyl+k5DdAknvlzdromjTgggVYhkSkf0qto8O71vfs7XFjfrB62/g9nEI9v5Y2Q0RnluV06qzwFeRhuWMMst6ZtlzGioPTuTmuJ8mDW0BNGOrfpksuKeEMkp2Nt80GoRx0C5kcKwYdUNQkPtMUYMT x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2lGEXp0y3lZd1GxZ2h8kfLjhvih9vCqbR" MIME-Version: 1.0 X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 780f0547-62b6-45ed-166e-08d79454e445 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2020 16:07:42.6190 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: R/4uczHKV/Zjg0S35bAtO4ipN2GZBRerCy2qHFhyJtav/SFrUX3xKUVAAPcUUCstrN23ixYZu8nSXPWMc15PWA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0285 Archived-At: Subject: Re: [Ace] remarks on draft-tiloca-ace-oscore-gm-admin-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 16:07:52 -0000 --2lGEXp0y3lZd1GxZ2h8kfLjhvih9vCqbR Content-Type: multipart/mixed; boundary="dKnHIkGj0Oy0MXydQy2XleRhrViaKB9Mh" --dKnHIkGj0Oy0MXydQy2XleRhrViaKB9Mh Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Jim, Thanks a lot for this review! We have been working on an updated version accessible at [1], which is already taking into account your comments on CoRAL. Please, find below inline some more replies and open points. Best, /Marco [1] https://gitlab.com/crimson84/draft-tiloca-ace-oscore-gm-admin/blob/v-01/d= raft-tiloca-ace-oscore-gm-admin.md On 2019-11-20 00:13, Jim Schaad wrote: > This is just going to be a high level review on how things are done rat= her > than a detailed review on each line of text. > > 1. - Go and read that CoRE Pub-Sub update document - you know the one t= hat > Klaus and friends have not managed to get written since the model propo= sal > was done way back when. Yes, we are now relying on an akin interface, along the lines of the now published draft https://datatracker.ietf.org/doc/draft-hartke-t2trg-coral-pubsub/ > > 2. Re-write this to use CoRAL - Yes I know that this makes another > dependency on getting it published from the CoRE group, but I don't wan= t to > do things multiple times. We have now also added examples in CoRAL, for all the interactions between Administrator and Group Manager, now also extended with FETCH for filtered retrieval. > > 3. I think that this document really needs to be able to be used with > HTTP/JSON as well as CoAP. If you can get the JSON version of CoRAL f= rom > Klaus then this falls out without any work. We are now saying the CoRAL examples are in text format, but they are in CBOR or JSON on the wire, with no particular additional effort. Is this enough? > > 4. Are you making it a requirement that the group name be the same as = the > group identifier assigned by the "group_name" parameter? If so then ha= ving > some type of title and description would seem to be almost mandatory. They are in fact the very same thing. The "group_name" parameter specifies the group name, as intended to identify the OSCORE group both by the administrator and the joining nodes in the other related documents. We can use only "invariant name" rather than "invariant identifier". Are we missing something? If so, what do you suggest we should give a title and description to? > > 5. There needs to be some parameters around pointing to the correct AS= and > so forth. The management API may reject because it does not trust the = AS. > Don't assume that this is a single value for the AS either. This is good and also aligned with other related drafts. If we interpret your suggestion correctly: 1) The POST request to /manage may specify also an optional 'as_uri' parameter, with the link to a suggested AS. The GM may accept the suggestion or not. If not, it has to think of an alternative AS, as valid issuer of tokens for joining that group. 2) The GM must have one more parameter in the group configuration with the effective AS URI, i.e. either one provided by the administrator and accepted, or one otherwise decided. Do you think of any additional related parameters to be included in the POST request, other than 'as_uri'? Perhaps the public key of the suggested AS if applicable? Do you think the suggestion in the request should actually be a list of AS, out of which the GM may pick up at most one? > > 6. You are missing a lot of management detail on the POST to the group= > node. Some of the things that are missing would be: > a) Is the group active or inactive We can have one more parameter on the group-configuration resource for th= is. We are interpreting active/inactive as follows. Ideally, upon creating the group, the request can specify the initial status as active or inactive. Upon later updating the group by sending a request to the group-configuration resource, the administrator can change the status (or read it through a GET). Then the active/inactive status has two parallel scopes: 1) one scope is for the GM alone, i.e the GM would allow the joining of new group members only if the group is set as active. 2) when the group is set as inactive, the current group members should refrain from sending and should not expect receiving any message protected with that group key material. However, there is no way to actually force them to. In support to scope (2), when the status changes to inactive, the GM should inform group members about that. To this end, the group-membership resource intended for group members would also include a parameter reflecting the group status and aligned in value with the one in the group-configuration resource. Then, there are two ways to inform the group members of a status change. a) A way is to have the group members observing the group-membership resource (that they may have been doing already anyway for notification-based rekeying). b) A second way is for the group members to have a dedicated local resources for this (and other) kind of control communication (e.g. rekeying). This is something we are also considering in ace-key-groupcomm(-oscore) for receiving individual rekeying messages. In either case this would require either: i) each node to provide the GM with the URI to such local resource, in the join request; or ii) the GM to include in the join response to each joining node a same multicast address targeting a local resource that that node has to create to receive control messages. > b) How does the server react if you change a the content encryption > algorithm, is this a simple re-key operation or is it more complicated An easy answer would be rekeying the group, just as for any other triggering reason. I agree this should be mention in this draft. However, I think a more elaborated description of what happens if the algorithm is changed (regardless why and how) should be actually better given in oscore-groupcomm (the what) and in ace-key-groupcomm-oscore (the how). > c) How does the server react if you change the signature algorithm? Th= is > would seem to be a much harder thing to do if the group is not empty or= not > active as everybody is going to need to re-join. Right. If the signature algorithm changes, the current public keys may be not compatible with it any longer. We see the following possible ways, assuming the current group members have learnt of the new algorithm in use. 1) The hard way, i.e. everyone leaving and re-joining. 2) A more lightweight way, i.e. relying on yet another operation for current group members on the GM, to upload a new public key consistent with the new algorithm. This would require to proof possession of the corresponding private key, as it is done upon joining. Probably, in this case, this can happen like we do in the Group OSCORE profile of ACE between the Client and the AS, see the bullet point on 'client_cred_verify' at [2]. And again it looks like details on the way this is done fits better in other documents. [2] https://tools.ietf.org/html/draft-tiloca-ace-group-oscore-profile-01#sect= ion-3.1 > d) Other parameter that are changed may be just as bad as changing the > signature algorithm - how the re-key is done jumps immediately to mind.= Yes, changing HKDF/Alg results in what discussed two replies above; changing anything else (thus related to signatures) results in what discussed in the reply above. > > 7. Is there currently any way for a KDC to signal to all of the member= s > that have joined that the key group no longer exists? A DELETE would s= eem > to indicate the need to be able to do this. Right, the DELETE of a group-configuration resource would trigger something like this. The current resource maintaining on the GM consists in: destroying both group-configuration and group-membership resource, then reply to the Administrator. That said, a possible extension to also inform current group members is akin to what we describe above about signaling that the group has moved to inactive state. That is: i) if group members observe the group-membership resource, a 4.04 notification is sent to them, upon deleting that resource. ii) if group members have their own local resource to receive control messages from the GM, a control message can inform about the deletion of such group-membership resource. This would be particularly convenient to be sent over multicast. This method (ii) would actually require the GM to send these messages to the group members first, and only afterwards actually delete the group-membership resource, in case information such as the destination addresses and URIs to consider are stored as part of the group-membership resource itself. A group member can of course discover what happened at any time, just by sending any type of request to the deleted group-membership resource and getting a 4.04 response back. The actual difference between an existing inactive group and a deleted group is that the latter has no way back, and would need to be re-created from scratch on the GM by the Administrator. > > Jim > > > --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --dKnHIkGj0Oy0MXydQy2XleRhrViaKB9Mh-- --2lGEXp0y3lZd1GxZ2h8kfLjhvih9vCqbR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl4V/kYACgkQ7iZktA5Y 2kPHNQf9Emw6rJtD/zkrS0nYsrhWeH+uo9169P88ZQeVyFnP0cxJly+4ehSQYGRt 3cxowFIZZcNY3qczRpOnXuw7lxiYMd/6o3bdCb1cieddhh1ze4P7qLt7+8FAJi8+ laCSixgYuDKJuO4Mg32XZ0zl32G58g2tuFWIMSObOyOWWjbAQs41ZUbJDzO5gP5X PCeBE9dEfT/M5jp9wm5B2qHGHxyCbuU9HXq6DVQj5xHWKpz+w0q14/bHNJbAdKgk wtqZQz4C6is4hJjNr5mZe6rHPqMD1SjyY8xNCgYx+ggH7Vgb3T7X6FJ1oY0J1HUX Xq+Y8EkfgkUJNyRpOmL7AGYf1OmwRQ== =4wm4 -----END PGP SIGNATURE----- --2lGEXp0y3lZd1GxZ2h8kfLjhvih9vCqbR-- From nobody Thu Jan 9 03:32:47 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0550C12007A; Thu, 9 Jan 2020 03:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPmZsL0px4vW; Thu, 9 Jan 2020 03:32:43 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0F1F12006F; Thu, 9 Jan 2020 03:32:42 -0800 (PST) Received: from wangari.tzi.org (p54BDE7FE.dip0.t-ipconnect.de [84.189.231.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 47tkVw6ST2z16Fy; Thu, 9 Jan 2020 12:32:40 +0100 (CET) From: Olaf Bergmann To: Jim Schaad Cc: , "'Benjamin Kaduk'" , References: <20200102234020.GI35479@kduck.mit.edu> <014601d5c2b8$9947acc0$cbd70640$@augustcellars.com> <878smkrjg0.fsf@wangari> <000801d5c4bc$cf418110$6dc48330$@augustcellars.com> Date: Thu, 09 Jan 2020 12:32:40 +0100 In-Reply-To: <000801d5c4bc$cf418110$6dc48330$@augustcellars.com> (Jim Schaad's message of "Mon, 6 Jan 2020 10:12:05 -0800") Message-ID: <87o8vclvaf.fsf@wangari> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 11:32:46 -0000 Hi Jim, Jim Schaad writes: > -----Original Message----- > From: Ace On Behalf Of Olaf Bergmann > Sent: Monday, January 6, 2020 2:03 AM > To: Jim Schaad > Cc: ace@ietf.org; 'Benjamin Kaduk' ; > draft-ietf-ace-dtls-authorize.all@ietf.org > Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 > > Jim, > > Jim Schaad writes: > > [Ben's review] >> We also are potentially in violation of the framework's requirements wit= h respect to the independent selection of profiles for client/AS and client= /RS interactions -- at present, when DTLS+RPK is used for client/RS, we req= uire that DTLS+RPK is also used for client/AS, in order to prove possession= of the key. We could perhaps weasel our way out by saying that the framew= ork's requirement applies at the profile granularity, and with symmetric PS= K we can be fully independent, but we still need to say something about thi= s property and the interaction with the framework's requirements. >> >> [JLS] I am missing where it is saying this. Can you give a pointer? I= don't believe that the POP of the RPK is required at the time that the tok= en is obtained. > > The problem is that AS must bind the Access Token to the RPK that the Cli= ent has presented, and the Client must use the very same RPK to establish t= he DTLS channel with RS. Otherwise, RS cannot be sure that AS has issued th= e Token to the same entity that is currently communicating with RS. > > [JLS] What if I do the following sequence of events: > 1. The AS is configured with RPK1 for the client and the client is confi= gured with RPK2 for the AS. > 2. The client and the AS run some type of POP algorithm, not currently s= pecified, to configure RPK3 into the AS for a second RPK to work with some = set of audiences (AUD1). > 3. The client then uses RPK1 to authenticate to the AS and asks for a ne= w token for AUD1 and provides (explicitly or implicitly RPK3). The AS know= s that it is tied to the client due to what happened in step 2. The AS the= n creates a new token for AUD1 which contains RPK3 for the client (and RPK4= for the RS) and returns it. > > The AS does a current POP for RPK1 when the token is being asked for. > The AS did a POP for RPK3 when it was placed into the system. > The AS has not done a POP for RPK4 - that was simply configured without t= hat step ever being done. The ACE framework has no ability for the AS to d= o the POP on RPK4 and ensure that it current. The client would do a POP wh= en the TLS session is created but has to rely on the AS that it is for the = correct RS. > > Note that the client can never generate a brand new RPK9 and send it to t= he AS in the token request because the AS will never have seen this before = and would need to run the POP algorithm of step 2 in order to assure that i= t is bound to the correct client and not pulled out of thin air. RPK9 coul= d not be used to authenticate the token request because the AS has no idea = what client it is tied to. okay, I see you have a valid point here. I will try to come up with some text that says that the AS must ensure that (in your scenario) RPK1 and RPK3 are bound to the same entity. Gr=C3=BC=C3=9Fe Olaf From nobody Thu Jan 9 12:17:27 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8EC120047; Thu, 9 Jan 2020 12:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AqUF5yEw-To; Thu, 9 Jan 2020 12:17:21 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D0931200E9; Thu, 9 Jan 2020 12:17:20 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 009KH0ME027683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 9 Jan 2020 15:17:03 -0500 Date: Thu, 9 Jan 2020 12:17:00 -0800 From: Benjamin Kaduk To: Olaf Bergmann Cc: Jim Schaad , ace@ietf.org, draft-ietf-ace-dtls-authorize.all@ietf.org Message-ID: <20200109201700.GF57294@kduck.mit.edu> References: <20200102234020.GI35479@kduck.mit.edu> <014601d5c2b8$9947acc0$cbd70640$@augustcellars.com> <878smkrjg0.fsf@wangari> <000801d5c4bc$cf418110$6dc48330$@augustcellars.com> <87o8vclvaf.fsf@wangari> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87o8vclvaf.fsf@wangari> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 20:17:25 -0000 On Thu, Jan 09, 2020 at 12:32:40PM +0100, Olaf Bergmann wrote: > Hi Jim, > > Jim Schaad writes: > > > -----Original Message----- > > From: Ace On Behalf Of Olaf Bergmann > > Sent: Monday, January 6, 2020 2:03 AM > > To: Jim Schaad > > Cc: ace@ietf.org; 'Benjamin Kaduk' ; > > draft-ietf-ace-dtls-authorize.all@ietf.org > > Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 > > > > Jim, > > > > Jim Schaad writes: > > > > [Ben's review] > >> We also are potentially in violation of the framework's requirements with respect to the independent selection of profiles for client/AS and client/RS interactions -- at present, when DTLS+RPK is used for client/RS, we require that DTLS+RPK is also used for client/AS, in order to prove possession of the key. We could perhaps weasel our way out by saying that the framework's requirement applies at the profile granularity, and with symmetric PSK we can be fully independent, but we still need to say something about this property and the interaction with the framework's requirements. > >> > >> [JLS] I am missing where it is saying this. Can you give a pointer? I don't believe that the POP of the RPK is required at the time that the token is obtained. > > > > The problem is that AS must bind the Access Token to the RPK that the Client has presented, and the Client must use the very same RPK to establish the DTLS channel with RS. Otherwise, RS cannot be sure that AS has issued the Token to the same entity that is currently communicating with RS. > > > > [JLS] What if I do the following sequence of events: > > 1. The AS is configured with RPK1 for the client and the client is configured with RPK2 for the AS. > > 2. The client and the AS run some type of POP algorithm, not currently specified, to configure RPK3 into the AS for a second RPK to work with some set of audiences (AUD1). > > 3. The client then uses RPK1 to authenticate to the AS and asks for a new token for AUD1 and provides (explicitly or implicitly RPK3). The AS knows that it is tied to the client due to what happened in step 2. The AS then creates a new token for AUD1 which contains RPK3 for the client (and RPK4 for the RS) and returns it. > > > > The AS does a current POP for RPK1 when the token is being asked for. > > The AS did a POP for RPK3 when it was placed into the system. > > The AS has not done a POP for RPK4 - that was simply configured without that step ever being done. The ACE framework has no ability for the AS to do the POP on RPK4 and ensure that it current. The client would do a POP when the TLS session is created but has to rely on the AS that it is for the correct RS. > > > > Note that the client can never generate a brand new RPK9 and send it to the AS in the token request because the AS will never have seen this before and would need to run the POP algorithm of step 2 in order to assure that it is bound to the correct client and not pulled out of thin air. RPK9 could not be used to authenticate the token request because the AS has no idea what client it is tied to. > > okay, I see you have a valid point here. I will try to come up with some > text that says that the AS must ensure that (in your scenario) RPK1 and > RPK3 are bound to the same entity. Jim's proposal seems broadly reasonable (though I think in general there needs to be some AS contributory nature in order to get proof of current possession of RPK3 at the time of (2). I think I would phrase it as "in possession of the same entity" rather than "bound to the same entity", though. -Ben From nobody Thu Jan 9 12:27:31 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B7C120801; Thu, 9 Jan 2020 12:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSq6jzETynQx; Thu, 9 Jan 2020 12:27:24 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ECBF1202A0; Thu, 9 Jan 2020 12:27:24 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 009KRBEJ031394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 9 Jan 2020 15:27:13 -0500 Date: Thu, 9 Jan 2020 12:27:10 -0800 From: Benjamin Kaduk To: Jim Schaad Cc: draft-ietf-ace-dtls-authorize.all@ietf.org, ace@ietf.org Message-ID: <20200109202710.GG57294@kduck.mit.edu> References: <20200102234020.GI35479@kduck.mit.edu> <014601d5c2b8$9947acc0$cbd70640$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <014601d5c2b8$9947acc0$cbd70640$@augustcellars.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 20:27:29 -0000 On Fri, Jan 03, 2020 at 08:36:54PM -0800, Jim Schaad wrote: >=20 >=20 > -----Original Message----- > From: Benjamin Kaduk =20 > Sent: Thursday, January 2, 2020 3:40 PM > To: draft-ietf-ace-dtls-authorize.all@ietf.org > Cc: ace@ietf.org > Subject: AD review of draft-ietf-ace-dtls-authorize-09 >=20 > Hi all, >=20 > Some high-level remarks before delving into the section-by-section > comments: >=20 > This document is pretty clearly DTLS 1.2-specific -- it talks about parti= cular protocol messages, message fields, and cipher suites that simply do n= ot apply to DTLS 1.3. In order to use this profile with DTLS 1.3, we'd nee= d to specify the analogous behavior/requirements to these (including standa= lone signature schemes and key-exchange groups, which are now both separate= ly negotiated from the cipher suite). > Given that DTLS 1.3 is past WGLC and only a few documents behind this one= in my review queue, it seems fairly prudent to spend some time and cover h= ow DTLS 1.3 would work here, since otherwise this document will become stal= e shortly after (or even before!) its publication as an RFC. >=20 > [JLS] Yes we need to look at this, but we also know who's fault this is = =F0=9F=98=89 Part of me wants to punt this off to the CoRE working group b= ecause the way they are currently using DTLS 1.2 is quite restrictive and t= hey really need to do a DTLS 1.3 document. I hadn't realized that the CoRE usage of DTLS was so restrictive; in that case we may have to wait for them, yes. >=20 > There's probably some additional discussion to include about the usage of= key identifiers in this document versus the potential uses described in th= e core framework. Specifically, the framework reminds us that "no assumpti= ons should be made that it is unique in the domains of either the client or= the RS" yet this document is using the kid as input to a KDF that produces= keys that must be unique across all clients, and allowing live/instant aut= horization updates based on matching "kid". > How shall we resolve this apparent conflict? >=20 > [JLS] I am having a problem seeing what the conflict is here. The "kid" = is a publicly known value so that fact that it is included in the KDF is no= t what is going to produce unique keys for all clients no matter what. It = is the secret that is going to make things unique. There is a potential pr= oblem with the fact that the RS may get two different entities that registe= r a token which has the same kid value, but that is a known issue for (D)TL= S. This is one of the reasons that the token itself can be used as the "ki= d" for DTLS. I think I'm just thinking about what you note as the "potential problem" where an RS receives two tokens with the same kid value but that are for different clients. For asymmetric PoP we require POST to authz-info, and since "POST a new token with the same kid" is the way we update permissions without changing DTLS keys, the RS needs to know to scope its lookup/storage based on (client,kid) (or more?) and not just 'kid'. Maybe this is obvious, but I wasn't sure. > We also are potentially in violation of the framework's requirements with= respect to the independent selection of profiles for client/AS and client/= RS interactions -- at present, when DTLS+RPK is used for client/RS, we requ= ire that DTLS+RPK is also used for client/AS, in order to prove possession = of the key. We could perhaps weasel our way out by saying that the framewo= rk's requirement applies at the profile granularity, and with symmetric PSK= we can be fully independent, but we still need to say something about this= property and the interaction with the framework's requirements. >=20 > [JLS] I am missing where it is saying this. Can you give a pointer? I = don't believe that the POP of the RPK is required at the time that the toke= n is obtained. [Olaf got this; thanks Olaf!] > This profile is mostly applicable to the client/RS communications and fee= ls like it only provides some of the picture for use with client/AS interac= tions. (It doesn't really say much of anything about RS/AS > interactions.) The introductory discussion does not do a great job of pai= nting that picture, and I'd like to see it more clearly introduced that the= bulk of our coverage is for the client/RS interaction. We also lean heavi= ly on the existing out-of-band configuration and key material shared betwee= n client and AS to secure the client/AS communications; we could probably t= ighten up the discussion about exactly what parameters of client/AS communi= cation are specified by this profile. >=20 > [JLS] I think this makes sense. >=20 > We do not say anything about DTLS session resumption (or renegotiation, t= hough not talking about that one is perfectly fine); that's a fairly core D= TLS concept that we should give some guidance on. >=20 > [JLS] I don't see any reason to talk about renegotiation, either it is do= ne or it isn't and a new connection would need to be created. I am not sur= e what to say about session resumption. This is something that really nee= ds to be dealt with in the CoRE working group before anything can be said h= ere. Session resumption would only resume the TLS session, but any CoRE st= ate above it is not going to be restored because it is defined as going awa= y in RFC 7252. This is currently also true for doing a renegotiation. We could just have a single-sentence note that "DTLS session resumption is an option to amortize RPK asymmetric crypto handshake costs, but CoRE state will be reinitialized in such case (Section X of [RFC 7252])". Or am I misunderstanding? -Ben > Looking through Appendix C ("Requirements on Profiles") of the framework,= do we want to say anything about: >=20 > - using the client credentials grant with this profile, as that's IIRC > the only example we show > - require that DTLS be used in a mode that provides replay protection > - when the client uses the authz-info endpoint instead of the > "psk_identity" field to convey the token to the RS, how does the RS > know which client is connecting (and thus what PSK to use), and what > does the client actually *put* in the "psk_identity" field? (The > other aspects of "how to select a proof-of-possession protocol" seem > to fall out naturally from the DTLS usage.) > - whether/how introspection is used? > - give more details of what this profile mandates when used for > client/AS interactions (as mentioned above) > - explicitly state that the authz-info endpoint is unprotected (or that > it might be protected if, e.g., the RS has a trustable certificate > that would be used instead of RPK or PSK, or by supplying the > token as the "psk_identity" when symmetric PoP is used, or by only > doing server-authentication with RPK as known by the client by the > rs_cnf access information >=20 > And now, on to the section-by-section comments. >=20 > Section 1 >=20 > a DTLS session. The communication between client and authorization > server may also be secured with DTLS. This specification supports > DTLS with Raw Public Keys (RPK) [RFC7250] and with Pre-Shared Keys > (PSK) [RFC4279]. >=20 > [DTLS 1.3 will inherit TLS 1.3's built-in support for (so-called > "external") PSKs.] >=20 > The DTLS handshake requires the client and server to prove that they > can use certain keying material. In the RPK mode, the client proves > with the DTLS handshake that it can use the RPK bound to the token > and the server shows that it can use a certain RPK. The access token > must be presented to the resource server. For the RPK mode, the > access token needs to be uploaded to the resource server before the > handshake is initiated, as described in Section 5.8.1 of the ACE > framework [I-D.ietf-ace-oauth-authz]. >=20 > This seems to be making some implicit assumptions about the message flow = that have not yet been covered by this document and are only somewhat cover= ed by the core framework spec. I'd propose: >=20 > % The ACE framework requires that client and server mutually % authenti= cate each other before any other protocol exchanges take % place. In orde= r for DTLS to provide mutual authentication, both % client and server must= prove their ability to use certain keying % material (tied to the authent= icated identity) as part of the DTLS % handshake. The AS assists in this = process by incorporating key % material (or information about key material= ) into the access token, % which is considered a "proof of possession" tok= en. In the RPK mode, % the client proves that it can use the RPK bound to= the token and the % server shows that it can use a certain RPK (as indica= ted by the AS to % the client). The resource server needs access to the t= oken in order % to complete this exchange. For the RPK mode, the access t= oken needs % to be uploaded to the resource server before the handshake is= % initiated, as described in Section 5.8.1 of the ACE framework % [I-D.i= etf-ace-oauth-authz]. >=20 > though I recognize that my text tends to be a bit more verbose than is st= rictly needed, so please feel free to edit it down. >=20 > Section 2 >=20 > The CoAP-DTLS profile for ACE specifies the transfer of > authentication information and, if necessary, authorization > information between the client (C) and the resource server (RS) > during setup of a DTLS session for CoAP messaging. It also specifies > how C can use CoAP over DTLS to retrieve an access token from the > authorization server (AS) for a protected resource hosted on the > resource server. >=20 > I suggest reiterating that "As specified in Section 6.7 of [I-D.ietf-ace-= oauth-authz], use of DTLS for one or both of these interactions is complete= ly independent". >=20 > To determine the AS in charge of a resource hosted at the RS, C MAY > send an initial Unauthorized Resource Request message to the RS. The >=20 > This is part of the core framework, so the "MAY" may be overkill. > (Lowercase "can" would do just fine.) >=20 > Once the client knows the authorization server's address, it can send > an access token request to the token endpoint at the AS as specified >=20 > Hmm. There's some level of "the client needs to have already been config= ured that that AS is a valid AS" verification that's done here, but I'm not= sure if that's too much detail to include at this stage (since we're reall= y just summarizing the framework here). >=20 > in [I-D.ietf-ace-oauth-authz]. As the access token request as well > as the response may contain confidential data, the communication > between the client and the authorization server MUST be >=20 > (This "MUST" is already a requirement from the core framework, so we don'= t necessarily need to repeat it as normative language.) >=20 > confidentiality-protected and ensure authenticity. C may have been > registered at the AS via the OAuth 2.0 client registration mechanism > as outlined in Section 5.3 of [I-D.ietf-ace-oauth-authz]. >=20 > Section 5.3 of oauth-authz says that registration is "out of scope"; is t= his still the right reference? >=20 > [I-D.ietf-ace-oauth-authz]. In case the client uses a symmetric > proof-of-possession key in the DTLS handshake, the procedure as above > MAY be used, or alternatively, the access token MAY instead be > transferred in the DTLS ClientKeyExchange message (see > Section 3.3.1). >=20 > (This is not DTLS 1.3-compatible.) >=20 > Section 3 >=20 > secured. Depending on the used CoAP security mode (see also > Section 9 of [RFC7252], the Client-to-AS request, AS-to-Client > response and DTLS session establishment carry slightly different > information. [...] >=20 > At this point in the document it's pretty unclear what "Client-to-AS requ= est", "AS-to-Client response", and "DTLS session establishment" are and how= they relate to each other. >=20 > Also, it seems like the behavior in Section 3.2 and 3.3 are relating to t= he mode used for the client/RS interactions, which relates to the client/AS= interactions only in the form of how PoP information is bound to/with the = token. >=20 > Section 3.1 >=20 > establish a secure communication channel. C MUST securely have > obtained keying material to communicate with AS. Furthermore, C MUST > verify that AS is authorized to provide access tokens (including > authorization information) about RS to C. Also, AS MUST securely > have obtained keying material for C, and obtained authorization rules > approved by the resource owner (RO) concerning C and RS that relate > to this keying material. [...] >=20 > The way this is written right now, we're going to get lots of questions f= rom reviewers about "how does this happen?" and for more details about it. = We are effectively assuming that this stuff is all provisioned already as = part of the device configuration or during enrollment, we should say someth= ing about these being requirements on device provisioning, not on the opera= tion of the ACE protocol. >=20 > between C and AS is bootstrapped is not part of this document. C and > AS MUST ensure the confidentiality, integrity and authenticity of all > exchanged messages. >=20 > I think this is also restating requirements from the core framework, and = may not need normative language in this manner. >=20 > Section 3.2 >=20 > I know that the section heading says "RawPublicKey Mode" already, but I'd= recommend adding a sentence in the preface that repeats that "When the cli= ent and RS use RawPublicKey authentication, the procedure is as follows"; w= e might get complaints otherwise that we are saying that the client MUST do= things that are not universal requirements. > (Section 3.3 does already have something like this for the symmetric-key > case.) >=20 > previously made known to the authorization server. To prove that the > client is in possession of this key, C MUST use the same keying > material that it uses to secure the communication with AS, e.g., the > DTLS session. >=20 > This seems in conflict with the core framework's requirement that the cli= ent/AS profile and client/RS profile are severable. >=20 > AS MUST check if the client that it communicates with is associated > with the RPK in the cnf object before issuing an access token to it. >=20 > Earlier in the section we noted a requirement to prove possession of the = key by using it in DTLS; why is there a separate "association" > requirement? > also, nit: "The AS". >=20 > which case it does not have to be sent. The response also contains > an access token and an "rs_cnf" parameter containing information > about the public key that is used by the resource server. AS MUST >=20 > nit(?): is the "rs_cnf" parameter always mandatory? (Or only when DTLS-R= PK is used for client-RS interactions?) > nit: "The AS" again (and throughought, to a large extent). >=20 > server that C wants to communicate with. AS MUST protect the > integrity of the token. If the access token contains confidential > data, AS MUST also protect the confidentiality of the access token. >=20 > This requirement ("protect the integrity of the token") feels a little un= derspecified, as it doesn't say protection over what workflow or who will v= erify the integrity (the RS). >=20 > C MUST ascertain that the access token response belongs to a certain > previously sent access token request, as the request may specify the > resource server with which C wants to communicate. >=20 > nit: I recomment rewording "belongs to", perhaps as "corresponds to". > DTLS can provide this guarantee when configured to do so, though it is no= t a guaranteed property from DTLS. >=20 > We'll probably get some grief about the "access_token" contents in the ex= ample not being valid CBOR, due to the parenthetical comment. We could pro= bably put a note in the preface that the value is truncated for readability= =2E Also, nit: "the client's" with article and apostrophe. >=20 > Section 3.2.1 >=20 > Before the client initiates the DTLS handshake with the resource > server, C MUST send a "POST" request containing the new access token > to the authz-info resource hosted by the resource server. After the > client >=20 > nit: we don't require single-use tokens, so "new" is probably overkill; j= ust "its access token" should suffice. > nit: formatting issue with spurious line break here. >=20 > server. To use the RawPublicKey mode, the client MUST specify the > public key that AS defined in the "cnf" field of the access token > response in the SubjectPublicKeyInfo structure in the DTLS handshake > as specified in [RFC7250]. >=20 > IIRC the access token response does not have to include a "cnf" field (e.= g., if the AS accepts the req_cnf from the request), so "defined in the fie= ld of the response" doesn't seem like quite the right wording. >=20 > An implementation that supports the RPK mode of this profile MUST at > least support the ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 >=20 > I understand that making the full-width-tag ciphersuite MTI would exclude= some devices, though it feels like some recommendation to use the full-len= gth tag when possible would be appropriate. That said, I do see that RFC 7= 252 makes no such remark, and thus consistency would have us not say anythi= ng either. >=20 > [RFC7251] with the ed25519 curve (cf. [RFC8032], [RFC8422]). >=20 > Just to be clear: ed25519 is an ECDSA algorithm; the corresponding ECDHE = operation is called x25519, and both algorithms make use of the elliptical = curve known as curve25519. Since we are using both ECDHE and ECDSA, it's p= robably simplest to just refer to "curve25519", though mentioning both ed25= 519 and x25519 would also work. >=20 > RS MUST check if the access token is still valid, if RS is the > intended destination, i.e., the audience, of the token, and if the > token was issued by an authorized AS. The access token is >=20 > nit: "i.e., the audience" is in effect a parenthetical, so using commas t= o offset it inside a comma-separated list is potentially confusing; I'd sug= gest using actual parentheses instead of commas around it. >=20 > reference to this key. If the authorization server has no certain > knowledge that the Client's key is already known to the resource > server, the Client's public key MUST be included in the access > token's "cnf" parameter. If CBOR web tokens [RFC8392] are used as > recommended in [I-D.ietf-ace-oauth-authz], keys MUST be encoded as > specified in [I-D.ietf-ace-cwt-proof-of-possession]. RS MUST use the >=20 > Is talking about """the access token's "cnf" parameter" consistent with a= llowing the use of non-CWT (non-JWT) token formats? >=20 > keying material in the handshake that AS specified in the rs_cnf > parameter in the access token. Thus, the handshake only finishes if > C and RS are able to use their respective keying material. >=20 > I suggest being explicit about "the DTLS handshake with the client", perh= aps as "MUST use in the DLTS handshake with the client the keying material = that the AS specified in the rs_cnf parameter in the access token". The sa= me caveat about "parameter in the access token" > applies here, though I guess there is an additional complication for "rs_= cnf" in that it's an token response parameter but I don't remember that we = say a huge amount about it also being included in the token itself -- the t= oken response is directed to the client but the token is directed to the RS. >=20 > Section 3.3 >=20 > token. AS MUST check if the identifier refers to a symmetric key > that was previously generated by AS as a shared secret for the > communication between this client and the resource server. >=20 > "What does the AS do if this check fails?" >=20 > The authorization server MUST determine the authorization rules for > the C it communicates with as defined by RO and generate the access >=20 > nit: it's surprising to see "authorization server" spelled out in the sam= e sentence as "C" and "RO" (which, incidentally, we don't seem to use in ab= breviation form anywhere other than where we define it). >=20 > wants to communicate with. Also, AS MUST protect the integrity of > the access token. If the token contains confidential data such as > the symmetric key, the confidentiality of the token MUST also be > protected. Depending on the requested token type and algorithm in >=20 > (same comment about "protect the integrity" or "protect" as for the RPK > case.) >=20 > that is to be used between C and the resource server. The access > token MUST be bound to the same symmetric key by means of the cnf > claim. >=20 > Now we call it a "claim" rather than a "token parameter", but this again = seems to be implicitly assuming CWT/JWT for tokens. > (Also, this "MUST" seems like something that the framework should guarant= ee and not a new requirement that the DTLS profile imposes.) >=20 > Figure 5: Example Access Token Request, symmetric PoP-key >=20 > Maybe we could include "(implicit)" in the caption, since symmetric PoP k= ey is the default. >=20 > An example access token response is illustrated in Figure 6. In this >=20 > Is it accurate to say "A corresponding example access token response"? > It's nice to the reader if we can tie the examples together like that. >=20 > Is the "Max-Age" usage in Figure 6 typical? (Also, similar comment about= having the parenthetical comment in the example body vs. preface.) >=20 > token_type : pop, >=20 > Didn't we switch this to being capitalized as "PoP"? >=20 > "COSE_Encrypt0" structure. The AS MUST use the keying material > shared with the RS to encrypt the token. >=20 > nit: I suggest s/shared with/it shares with/ >=20 > We should probably say something about why the kid in Figure 7 is differe= nt from the one in Figure 6. >=20 > 4.00 Bad Request > Content-Format: application/ace+cbor > Payload: > { > error : invalid_request > } >=20 > Figure 8: Example Access Token Response With Reject >=20 > RFC 6749's description of "invalid_request" seems to imply that it's most= ly about malformed requests, as opposed to the AS deciding that the client = is not authorized for any access to the requested resource (which is maybe = what's implied by the previous paragraph). This is not necessarily a probl= em, but perhaps we could make the text and example more consistent. >=20 > The method for how the resource server determines the symmetric key > from an access token containing only a key identifier is application > specific, the remainder of this section provides one example. >=20 > nit: hyphenate "application-specific", and this is a comma splice. >=20 > resource server. This key needs to be securely stored and processed > in the same way as the key used to protect the communication between > AS and RS. >=20 > nit: is this better as "processed" or "protected"? >=20 > The fields in the context information "COSE_KDF_Context" > (Section 11.2 of [RFC8152]) have the following values: >=20 > o AlgorithmID =3D "ACE-CoAP-DTLS-key-derivation" >=20 > RFC 8152 says that these AlgorithmID values come from the COSE Algorithms= registry, which this does not (unless we register it there, which we don't= currently). Also, since the output is used directly for DTLS PSK, I don't= think the "key-derivation" portion is needed. >=20 > o PartyUInfo =3D PartyVInfo =3D ( null, null, null ) >=20 > (8152 seems to prefer "nil" over "null".) >=20 > o keyDataLength needs to be defined by the application >=20 > o protected MUST be a zero length bstr >=20 > o other is a zero length bstr >=20 > (These three are all members of the "SuppPubInfo" field, which is not ver= y clear from how we include them in the same list as top-level > fields.) >=20 > Section 3.3.1 >=20 > When a client receives an access token response from an authorization > server, C MUST ascertain that the access token response belongs to a > certain previously sent access token request, as the request may > specify the resource server with which C wants to communicate. >=20 > (Same bit about "belongs to".) >=20 > If a resource server receives a ClientKeyExchange message that > contains a "psk_identity" with a length greater zero, it uses the > contents as index for its key store (i.e., treat the contents as key >=20 > (This is not DTLS 1.3-compatible.) > nits: "greater than", "as an index", "as a key identifier" >=20 > identifier). The resource server MUST check if it has one or more > access tokens that are associated with the specified key. >=20 > I don't understand this sentence -- isn't the access token the precise co= ntents of the "psk_identity" field, so that there would be a key associated= with the access token, not the other way around? >=20 > If no key with a matching identifier is found, the resource server > MAY process the contents of the "psk_identity" field as access token >=20 > Similarly here, the causality feels reversed. >=20 > continuing the DTLS handshake. If the contents of the "psk_identity" > do not yield a valid access token for the requesting client, the DTLS > session setup is terminated with an "illegal_parameter" DTLS alert > message. >=20 > I think "the RS aborts the DTLS handshake with an 'illegal_parameter' ale= rt" > would be more conventional phrasing. >=20 > Note2: According to [RFC7252], CoAP implementations MUST support the > ciphersuite TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]. A client is > therefore expected to offer at least this ciphersuite to the > resource server. >=20 > Do we want to say anything about the (EC)DHE variants? Short-lived acces= s tokens with the AS generating new symmetric keys can provide similar forw= ard-secrecy properties to using DHE, but there is in general a trend in the= IETF towards defaulting to providing forward secrecy in key exchanges. >=20 > When RS receives an access token, RS MUST check if the access token > is still valid, if RS is the intended destination, i.e., the audience > of the token, and if the token was issued by an authorized AS. This >=20 > As above, "i.e., the audience of the token" would probably be better when= offset in parentheses than by commas. >=20 > While the client can retrieve the shared secret from the contents of > the "cnf" parameter in the AS-to-Client response, the resource server > uses the information contained in the "cnf" claim of the access token > to determine the actual secret when no explicit "kid" was provided in > the "psk_identity" field. If key derivation is used, the RS uses the > "COSE_KDF_Context" information as described above. >=20 > "psk_identity" is a field in ClientKeyExchange, and we say that its conte= nts are the raw access token for our usage. It does not have a direct COSE= structure for this talk of "kid" to make much sense without further explan= ation. >=20 > Section 3.4 >=20 > We may get some requests for a more explicit definition of what the "auth= orization information" tied to a client is. >=20 > Once a DTLS channel has been established as described in Section 3.2 > and Section 3.3, respectively, the client is authorized to access >=20 > nit: I think "or" is more appropriate to join the sections listed, as onl= y one is applicable to a given connection. >=20 > With the successful establishment of the DTLS channel, C and RS have > proven that they can use their respective keying material. An access > token that is bound to the client's keying material is associated > with the channel. Any request that the resource server receives on > this channel MUST be checked against these authorization rules. RS >=20 > nit: I'd s/these/the following/ >=20 > MUST check for every request if the access token is still valid. > Incoming CoAP requests that are not authorized with respect to any > access token that is associated with the client MUST be rejected by > the resource server with 4.01 response as described in Section 5.1.1 > of [I-D.ietf-ace-oauth-authz]. >=20 > "any access token" implies there might be more than one, though I seem to= recall discussion of updated tokens overwriting any previous one, so that = only one token per client is active at any given time. What did we end up = settling on? >=20 > Also, the referenced framework Section 5.1.1 does not actually mandate th= e 4.01 response code. >=20 > The resource server SHOULD treat an incoming CoAP request as > authorized if the following holds: >=20 > We could say more about this "SHOULD" (or change the way we discuss it) > -- is it the minimum baseline of checks and additional checks may be appl= ied, or do some of them not apply in some cases, or ...? >=20 > Incoming CoAP requests received on a secure DTLS channel that are not > thus authorized MUST be rejected according to Section 5.8.2 of > [I-D.ietf-ace-oauth-authz] >=20 > We may also get some questions asking about what the difference is betwee= n the "not authorized with respect to any access token" in the previous quo= ted snippet" and "not thus authorized" in this quoted snippet. >=20 > The client cannot always know a priori if an Authorized Resource > Request will succeed. It MUST check the validity of its keying > material before sending a request or processing a response. If the >=20 > What does "check the validity of its keying material" mean? >=20 > client repeatedly gets error responses containing AS Creation Hints > (cf. Section 5.1.2 of [I-D.ietf-ace-oauth-authz] as response to its > requests, it SHOULD request a new access token from the authorization > server in order to continue communication with the resource server. >=20 > Why should this only be done in the case of *repeatedly* getting such err= or responses; I thought the idea of the AS Request Creation Hints was to ta= ke immediate effect. > (Also, nit: s/AS Creation Hints/AS Request Creation Hints/.) >=20 > Section 4 >=20 > The client can update the authorization information stored at the > resource server at any time without changing an established DTLS > session. To do so, the Client requests a new access token from the > authorization server for the intended action on the respective > resource and uploads this access token to the authz-info resource on > the resource server. >=20 > I suggest adding another sentence similar to "Because ACE tokens are proo= f-of-possession tokens, the updated authorization information only takes im= mediate effect if such proof has already been provided, e.g., if the PoP ke= y associated with the new token is the same as the one currently in use." = This is further detailed in the following paragraphs, but not stated concre= tely as a key principle. >=20 > Section 5 >=20 > DTLS sessions that have been established in accordance with this > profile are always tied to a specific access token. As this token >=20 > Doesn't the dynamic authorization update mechanism allow that token to be= swapped out during the lifetime of the connection? > Also, as a terminology point, I think "DTLS association" is more appropri= ate than "DTLS session" for what we describe, since the token is is tied to= the client and consulted at the start of the handshake, as opposed to bein= g a property of the DTLS session and carried across resumptions. >=20 > may become invalid at any time (e.g. because it has expired), the > session may become useless at some point. A resource server > therefore MUST terminate existing DTLS sessions after the access > token for this session has been deleted. >=20 > I assume that using "been deleted" vs. "has expired" is a deliberate choi= ce? If we don't say anything else about when to delete tokens, it doesn't = post much of a requirement, though. >=20 > Section 6 >=20 > endpoint. The use of CoAP and DTLS for this communication is > RECOMMENDED in this profile, other protocols (such as HTTP and TLS or > CoAP and OSCORE) MAY be used instead. >=20 > nit: comma splice > Also, we could potentially refer to the OSCORE profile document here (inf= ormatively). >=20 > If other means of securing the communication with the AS are used, > the security protocol MUST fulfill the communication security > requirements in Section 6.2 of [I-D.ietf-ace-oauth-authz]. >=20 > I suggest phrasing more like "the communication security requirements fro= m Section 6.2 of [I-D.ietf-ace-oauth-authz] remain applicable", since there= 's no need to add another MUST to the ones already in the framework documen= t. >=20 > Section 7 >=20 > I have a few suggestions for potential additions to this section as well = as comments on the existing contents. >=20 > We might consider adding a brief note about the use of 8-byte authenticat= ion tags in DTLS ciphers and how that affects the risk profile. >=20 > The use of "live" authorization upgrades on an existing DTLS connection b= y posting a new token to the authz-info endpoint does not provide much guar= antee about the order in which operations occur (and thus which authorizati= on info is used to process a given client request), especially in the face = of an attacker that can delay and reorder packets. This does not necessari= ly mean that we should not bother to define that mechanism, but we should p= oint out that there is only a weak ordering property provided, note that ot= her mechanisms should be used when strict serialization is important, and c= aution that when the later-issued token contains a reduction in authorizati= on from the initial token, it is impossible to guarantee that the reduction= in authorization will take effect prior to the expiration of the original = token. >=20 > We rely heavily on the AS to accurately provide binding of raw key materi= al to authorization information and endpoint identinty; I think this is a s= tronger reliance than just that implied by the core architecture, and so mi= ght merit a mention here. (This relates to all the checks about "MUST chec= k that [client/...] is associated with [RPK/PSK]" that appear throughout th= e document.) >=20 > I'd also suggest reiterating all the places where we rely on out-of-band = configuration, as there's always a risk of such configuration becoming stal= e (or getting attacked directly). >=20 > I'd consider reiterating that when the KDF scheme is in use between RS an= d AS, that kid uniqueness is paramount, as using the same kid for multiple = clients and the same RS would have potentially disasterous consequences in = that case. >=20 > Similarly (though this is inherent to symmetric PoP and may not actually = need reiterating), when we use symmetric PSKs for PoP, they lose almost all= value if any given PSK is known to more than one client or RS. (The secdi= r review on the framework has us putting in MUST-level requirements to not = share further than that, so it seems pretty reasonable to not duplicate tha= t warning here.) >=20 > This document specifies a profile for the Authentication and > Authorization for Constrained Environments (ACE) framework > [I-D.ietf-ace-oauth-authz]. As it follows this framework's general > approach, the general security considerations from section 6 also > apply to this profile. >=20 > (The HTMLized link will only do the right thing if you use the redundant = "section 6 of [I-D.ietf-ace-oauth-authz]".) >=20 > The use of multiple access tokens for a single client increases the > strain on the resource server as it must consider every access token > and calculate the actual permissions of the client. Also, tokens may > contradict each other which may lead the server to enforce wrong > permissions. If one of the access tokens expires earlier than > others, the resulting permissions may offer insufficient protection. > Developers SHOULD avoid using multiple access tokens for a client. >=20 > I think I touched on this above; did we want to make a stronger statement= about "only one active token per client"? >=20 > Section 8 >=20 > information as possible in an unencrypted response. When a DTLS > session between the client and the resource server already exists, > more detailed information MAY be included with an error response to > provide the client with sufficient information to react on that > particular error. >=20 > I'd suggest adding a caveat like "an authenticated client" or "a known cl= ient", since DTLS itself does not guarantee that the client is not an attac= ker. >=20 > Section 9 >=20 > Profile ID: 1 >=20 > I think this has to be merely a "suggested value", as IANA will control t= he actual allocations, in the absence of a reservation of this value in the= framework document. >=20 > Section 10.1 >=20 > We don't currently reference RFC 7925 in any way that would require it to= be a normative reference. We probably should, though -- somehow pull in t= hat we require/recommend conformance with that profile of DTLS. >=20 > Section 10.2 >=20 > I think RFCs 7250, 7251, and 8422 need to be normative. >=20 > Thanks, >=20 > Ben >=20 From nobody Thu Jan 9 12:53:10 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C8112013B; Thu, 9 Jan 2020 12:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyLtsxsezOr8; Thu, 9 Jan 2020 12:53:06 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4EE8120047; Thu, 9 Jan 2020 12:53:05 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 9 Jan 2020 12:52:58 -0800 From: Jim Schaad To: 'Benjamin Kaduk' , 'Olaf Bergmann' CC: , References: <20200102234020.GI35479@kduck.mit.edu> <014601d5c2b8$9947acc0$cbd70640$@augustcellars.com> <878smkrjg0.fsf@wangari> <000801d5c4bc$cf418110$6dc48330$@augustcellars.com> <87o8vclvaf.fsf@wangari> <20200109201700.GF57294@kduck.mit.edu> In-Reply-To: <20200109201700.GF57294@kduck.mit.edu> Date: Thu, 9 Jan 2020 12:52:56 -0800 Message-ID: <00b801d5c72e$c6dd42b0$5497c810$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHGCRF5nmwiv9SPGwzqJ8qbQfLFcAHlgxMZAtepCeUBXvgPxwIAJCZJAqEcdxanrF+j4A== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 20:53:08 -0000 -----Original Message----- From: Benjamin Kaduk Sent: Thursday, January 9, 2020 12:17 PM To: Olaf Bergmann Cc: Jim Schaad ; ace@ietf.org; draft-ietf-ace-dtls-authorize.all@ietf.org Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 On Thu, Jan 09, 2020 at 12:32:40PM +0100, Olaf Bergmann wrote: > Hi Jim, > > Jim Schaad writes: > > > -----Original Message----- > > From: Ace On Behalf Of Olaf Bergmann > > Sent: Monday, January 6, 2020 2:03 AM > > To: Jim Schaad > > Cc: ace@ietf.org; 'Benjamin Kaduk' ; > > draft-ietf-ace-dtls-authorize.all@ietf.org > > Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 > > > > Jim, > > > > Jim Schaad writes: > > > > [Ben's review] > >> We also are potentially in violation of the framework's requirements with respect to the independent selection of profiles for client/AS and client/RS interactions -- at present, when DTLS+RPK is used for client/RS, we require that DTLS+RPK is also used for client/AS, in order to prove possession of the key. We could perhaps weasel our way out by saying that the framework's requirement applies at the profile granularity, and with symmetric PSK we can be fully independent, but we still need to say something about this property and the interaction with the framework's requirements. > >> > >> [JLS] I am missing where it is saying this. Can you give a pointer? I don't believe that the POP of the RPK is required at the time that the token is obtained. > > > > The problem is that AS must bind the Access Token to the RPK that the Client has presented, and the Client must use the very same RPK to establish the DTLS channel with RS. Otherwise, RS cannot be sure that AS has issued the Token to the same entity that is currently communicating with RS. > > > > [JLS] What if I do the following sequence of events: > > 1. The AS is configured with RPK1 for the client and the client is configured with RPK2 for the AS. > > 2. The client and the AS run some type of POP algorithm, not currently specified, to configure RPK3 into the AS for a second RPK to work with some set of audiences (AUD1). > > 3. The client then uses RPK1 to authenticate to the AS and asks for a new token for AUD1 and provides (explicitly or implicitly RPK3). The AS knows that it is tied to the client due to what happened in step 2. The AS then creates a new token for AUD1 which contains RPK3 for the client (and RPK4 for the RS) and returns it. > > > > The AS does a current POP for RPK1 when the token is being asked for. > > The AS did a POP for RPK3 when it was placed into the system. > > The AS has not done a POP for RPK4 - that was simply configured without that step ever being done. The ACE framework has no ability for the AS to do the POP on RPK4 and ensure that it current. The client would do a POP when the TLS session is created but has to rely on the AS that it is for the correct RS. > > > > Note that the client can never generate a brand new RPK9 and send it to the AS in the token request because the AS will never have seen this before and would need to run the POP algorithm of step 2 in order to assure that it is bound to the correct client and not pulled out of thin air. RPK9 could not be used to authenticate the token request because the AS has no idea what client it is tied to. > > okay, I see you have a valid point here. I will try to come up with > some text that says that the AS must ensure that (in your scenario) > RPK1 and > RPK3 are bound to the same entity. Jim's proposal seems broadly reasonable (though I think in general there needs to be some AS contributory nature in order to get proof of current possession of RPK3 at the time of (2). I think I would phrase it as "in possession of the same entity" rather than "bound to the same entity", though. [JLS] If I was to write this out as a real protocol, it would end up something along the lines of Sign(RPK1, Sign(RPK3, RPK1 || RPK3 || AS Nonce || Client Nonce )) so that we know that both keys are in the possession of a single entity (or a cabal collaborating) and it is current to the run of the POP protocol. Jim -Ben From nobody Thu Jan 9 13:19:11 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD13F12080F; Thu, 9 Jan 2020 13:19:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LauvAQ2fXbca; Thu, 9 Jan 2020 13:19:05 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E032B120807; Thu, 9 Jan 2020 13:19:04 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 9 Jan 2020 13:18:58 -0800 From: Jim Schaad To: 'Benjamin Kaduk' CC: , References: <20200102234020.GI35479@kduck.mit.edu> <014601d5c2b8$9947acc0$cbd70640$@augustcellars.com> <20200109202710.GG57294@kduck.mit.edu> In-Reply-To: <20200109202710.GG57294@kduck.mit.edu> Date: Thu, 9 Jan 2020 13:18:55 -0800 Message-ID: <00bb01d5c732$68480420$38d80c60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHGCRF5nmwiv9SPGwzqJ8qbQfLFcAHlgxMZAV4RnuSn6C8EIA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 21:19:10 -0000 -----Original Message----- From: Benjamin Kaduk =20 Sent: Thursday, January 9, 2020 12:27 PM To: Jim Schaad Cc: draft-ietf-ace-dtls-authorize.all@ietf.org; ace@ietf.org Subject: Re: AD review of draft-ietf-ace-dtls-authorize-09 On Fri, Jan 03, 2020 at 08:36:54PM -0800, Jim Schaad wrote: >=20 >=20 > -----Original Message----- > From: Benjamin Kaduk > Sent: Thursday, January 2, 2020 3:40 PM > To: draft-ietf-ace-dtls-authorize.all@ietf.org > Cc: ace@ietf.org > Subject: AD review of draft-ietf-ace-dtls-authorize-09 >=20 > Hi all, >=20 > Some high-level remarks before delving into the section-by-section > comments: >=20 > This document is pretty clearly DTLS 1.2-specific -- it talks about = particular protocol messages, message fields, and cipher suites that = simply do not apply to DTLS 1.3. In order to use this profile with DTLS = 1.3, we'd need to specify the analogous behavior/requirements to these = (including standalone signature schemes and key-exchange groups, which = are now both separately negotiated from the cipher suite). > Given that DTLS 1.3 is past WGLC and only a few documents behind this = one in my review queue, it seems fairly prudent to spend some time and = cover how DTLS 1.3 would work here, since otherwise this document will = become stale shortly after (or even before!) its publication as an RFC. >=20 > [JLS] Yes we need to look at this, but we also know who's fault this = is =F0=9F=98=89 Part of me wants to punt this off to the CoRE working = group because the way they are currently using DTLS 1.2 is quite = restrictive and they really need to do a DTLS 1.3 document. I hadn't realized that the CoRE usage of DTLS was so restrictive; in = that case we may have to wait for them, yes. [JLS] Yeah, I really ought to start writing this document. The first = time I read the DTLS section and realized that when a re-key operation = occurred that all of the current state on the server is to be cleared as = if a new session had just been negotiated I just about went crazy. They = were worried about the security implications on the key roll over which = made no sense to me, but then I am much more versed in TLS than they = were. >=20 > There's probably some additional discussion to include about the usage = of key identifiers in this document versus the potential uses described = in the core framework. Specifically, the framework reminds us that "no = assumptions should be made that it is unique in the domains of either = the client or the RS" yet this document is using the kid as input to a = KDF that produces keys that must be unique across all clients, and = allowing live/instant authorization updates based on matching "kid". > How shall we resolve this apparent conflict? >=20 > [JLS] I am having a problem seeing what the conflict is here. The = "kid" is a publicly known value so that fact that it is included in the = KDF is not what is going to produce unique keys for all clients no = matter what. It is the secret that is going to make things unique. = There is a potential problem with the fact that the RS may get two = different entities that register a token which has the same kid value, = but that is a known issue for (D)TLS. This is one of the reasons that = the token itself can be used as the "kid" for DTLS. I think I'm just thinking about what you note as the "potential problem" where an RS receives two tokens with the same kid value but that are for = different clients. For asymmetric PoP we require POST to authz-info, = and since "POST a new token with the same kid" is the way we update = permissions without changing DTLS keys, the RS needs to know to scope = its lookup/storage based on (client,kid) (or more?) and not just 'kid'. = Maybe this is obvious, but I wasn't sure. [JLS] No, "POST a new token with the same KEY" is the way that we update = permissions without changing the DTLS keys. For RPK this is easy. For = symmetric keys this is a harder sell and you really need to add some = additional checks to make it something along the lines of same . There may not be a key id if one is using the token as the user = identifier when doing the DTLS protocol so matching on kid would seem to = be difficult there. What I was referring to as the potential problem is = that if client 1 posts a token with a symmetric key and KID1 and uses = KID1 as the user name things are fine. Now if client 2 posts a token = with a different symmetric key and KID1. Client 2 can use KID1 as the = user name to connect to the server but if client 1 attempts to connect = with KID1 as the user name it will fail doing the connection. This is a = (D)TLS issue as you cannot do a "retry" easily in TLS 1.2. (Ding, = ding, ding, ding. Jim just realizes that TLS 1.3 might have solved = this problem with the PSK binder and should do research to find out if = this is true.) > We also are potentially in violation of the framework's requirements = with respect to the independent selection of profiles for client/AS and = client/RS interactions -- at present, when DTLS+RPK is used for = client/RS, we require that DTLS+RPK is also used for client/AS, in order = to prove possession of the key. We could perhaps weasel our way out by = saying that the framework's requirement applies at the profile = granularity, and with symmetric PSK we can be fully independent, but we = still need to say something about this property and the interaction with = the framework's requirements. >=20 > [JLS] I am missing where it is saying this. Can you give a pointer? = I don't believe that the POP of the RPK is required at the time that the = token is obtained. [Olaf got this; thanks Olaf!] > This profile is mostly applicable to the client/RS communications and=20 > feels like it only provides some of the picture for use with client/AS = > interactions. (It doesn't really say much of anything about RS/AS > interactions.) The introductory discussion does not do a great job of = painting that picture, and I'd like to see it more clearly introduced = that the bulk of our coverage is for the client/RS interaction. We also = lean heavily on the existing out-of-band configuration and key material = shared between client and AS to secure the client/AS communications; we = could probably tighten up the discussion about exactly what parameters = of client/AS communication are specified by this profile. >=20 > [JLS] I think this makes sense. >=20 > We do not say anything about DTLS session resumption (or = renegotiation, though not talking about that one is perfectly fine); = that's a fairly core DTLS concept that we should give some guidance on. >=20 > [JLS] I don't see any reason to talk about renegotiation, either it is = done or it isn't and a new connection would need to be created. I am = not sure what to say about session resumption. This is something that = really needs to be dealt with in the CoRE working group before anything = can be said here. Session resumption would only resume the TLS session, = but any CoRE state above it is not going to be restored because it is = defined as going away in RFC 7252. This is currently also true for = doing a renegotiation. We could just have a single-sentence note that "DTLS session resumption = is an option to amortize RPK asymmetric crypto handshake costs, but CoRE = state will be reinitialized in such case (Section X of [RFC 7252])". Or = am I misunderstanding? [JLS] I think that this should be in the CoRE document. If they change = their minds about this then the sentence would become out of date. jim -Ben > Looking through Appendix C ("Requirements on Profiles") of the = framework, do we want to say anything about: >=20 > - using the client credentials grant with this profile, as that's IIRC > the only example we show > - require that DTLS be used in a mode that provides replay protection > - when the client uses the authz-info endpoint instead of the > "psk_identity" field to convey the token to the RS, how does the RS > know which client is connecting (and thus what PSK to use), and what > does the client actually *put* in the "psk_identity" field? (The > other aspects of "how to select a proof-of-possession protocol" seem > to fall out naturally from the DTLS usage.) > - whether/how introspection is used? > - give more details of what this profile mandates when used for > client/AS interactions (as mentioned above) > - explicitly state that the authz-info endpoint is unprotected (or = that > it might be protected if, e.g., the RS has a trustable certificate > that would be used instead of RPK or PSK, or by supplying the > token as the "psk_identity" when symmetric PoP is used, or by only > doing server-authentication with RPK as known by the client by the > rs_cnf access information >=20 > And now, on to the section-by-section comments. >=20 > Section 1 >=20 > a DTLS session. The communication between client and authorization > server may also be secured with DTLS. This specification supports > DTLS with Raw Public Keys (RPK) [RFC7250] and with Pre-Shared Keys > (PSK) [RFC4279]. >=20 > [DTLS 1.3 will inherit TLS 1.3's built-in support for (so-called > "external") PSKs.] >=20 > The DTLS handshake requires the client and server to prove that = they > can use certain keying material. In the RPK mode, the client = proves > with the DTLS handshake that it can use the RPK bound to the token > and the server shows that it can use a certain RPK. The access = token > must be presented to the resource server. For the RPK mode, the > access token needs to be uploaded to the resource server before the > handshake is initiated, as described in Section 5.8.1 of the ACE > framework [I-D.ietf-ace-oauth-authz]. >=20 > This seems to be making some implicit assumptions about the message = flow that have not yet been covered by this document and are only = somewhat covered by the core framework spec. I'd propose: >=20 > % The ACE framework requires that client and server mutually % = authenticate each other before any other protocol exchanges take % = place. In order for DTLS to provide mutual authentication, both % = client and server must prove their ability to use certain keying % = material (tied to the authenticated identity) as part of the DTLS % = handshake. The AS assists in this process by incorporating key % = material (or information about key material) into the access token, % = which is considered a "proof of possession" token. In the RPK mode, % = the client proves that it can use the RPK bound to the token and the % = server shows that it can use a certain RPK (as indicated by the AS to % = the client). The resource server needs access to the token in order % = to complete this exchange. For the RPK mode, the access token needs % = to be uploaded to the resource server before the handshake is % = initiated, as described in Section 5.8.1 of the ACE framework % = [I-D.ietf-ace-oauth-authz]. >=20 > though I recognize that my text tends to be a bit more verbose than is = strictly needed, so please feel free to edit it down. >=20 > Section 2 >=20 > The CoAP-DTLS profile for ACE specifies the transfer of > authentication information and, if necessary, authorization > information between the client (C) and the resource server (RS) > during setup of a DTLS session for CoAP messaging. It also = specifies > how C can use CoAP over DTLS to retrieve an access token from the > authorization server (AS) for a protected resource hosted on the > resource server. >=20 > I suggest reiterating that "As specified in Section 6.7 of = [I-D.ietf-ace-oauth-authz], use of DTLS for one or both of these = interactions is completely independent". >=20 > To determine the AS in charge of a resource hosted at the RS, C MAY > send an initial Unauthorized Resource Request message to the RS. =20 > The >=20 > This is part of the core framework, so the "MAY" may be overkill. > (Lowercase "can" would do just fine.) >=20 > Once the client knows the authorization server's address, it can = send > an access token request to the token endpoint at the AS as=20 > specified >=20 > Hmm. There's some level of "the client needs to have already been = configured that that AS is a valid AS" verification that's done here, = but I'm not sure if that's too much detail to include at this stage = (since we're really just summarizing the framework here). >=20 > in [I-D.ietf-ace-oauth-authz]. As the access token request as well > as the response may contain confidential data, the communication > between the client and the authorization server MUST be >=20 > (This "MUST" is already a requirement from the core framework, so we=20 > don't necessarily need to repeat it as normative language.) >=20 > confidentiality-protected and ensure authenticity. C may have been > registered at the AS via the OAuth 2.0 client registration = mechanism > as outlined in Section 5.3 of [I-D.ietf-ace-oauth-authz]. >=20 > Section 5.3 of oauth-authz says that registration is "out of scope"; = is this still the right reference? >=20 > [I-D.ietf-ace-oauth-authz]. In case the client uses a symmetric > proof-of-possession key in the DTLS handshake, the procedure as = above > MAY be used, or alternatively, the access token MAY instead be > transferred in the DTLS ClientKeyExchange message (see > Section 3.3.1). >=20 > (This is not DTLS 1.3-compatible.) >=20 > Section 3 >=20 > secured. Depending on the used CoAP security mode (see also > Section 9 of [RFC7252], the Client-to-AS request, AS-to-Client > response and DTLS session establishment carry slightly different > information. [...] >=20 > At this point in the document it's pretty unclear what "Client-to-AS = request", "AS-to-Client response", and "DTLS session establishment" are = and how they relate to each other. >=20 > Also, it seems like the behavior in Section 3.2 and 3.3 are relating = to the mode used for the client/RS interactions, which relates to the = client/AS interactions only in the form of how PoP information is bound = to/with the token. >=20 > Section 3.1 >=20 > establish a secure communication channel. C MUST securely have > obtained keying material to communicate with AS. Furthermore, C = MUST > verify that AS is authorized to provide access tokens (including > authorization information) about RS to C. Also, AS MUST securely > have obtained keying material for C, and obtained authorization = rules > approved by the resource owner (RO) concerning C and RS that relate > to this keying material. [...] >=20 > The way this is written right now, we're going to get lots of = questions from reviewers about "how does this happen?" and for more = details about it. We are effectively assuming that this stuff is all = provisioned already as part of the device configuration or during = enrollment, we should say something about these being requirements on = device provisioning, not on the operation of the ACE protocol. >=20 > between C and AS is bootstrapped is not part of this document. C = and > AS MUST ensure the confidentiality, integrity and authenticity of = all > exchanged messages. >=20 > I think this is also restating requirements from the core framework, = and may not need normative language in this manner. >=20 > Section 3.2 >=20 > I know that the section heading says "RawPublicKey Mode" already, but = I'd recommend adding a sentence in the preface that repeats that "When = the client and RS use RawPublicKey authentication, the procedure is as = follows"; we might get complaints otherwise that we are saying that the = client MUST do things that are not universal requirements. > (Section 3.3 does already have something like this for the=20 > symmetric-key > case.) >=20 > previously made known to the authorization server. To prove that = the > client is in possession of this key, C MUST use the same keying > material that it uses to secure the communication with AS, e.g., = the > DTLS session. >=20 > This seems in conflict with the core framework's requirement that the = client/AS profile and client/RS profile are severable. >=20 > AS MUST check if the client that it communicates with is associated > with the RPK in the cnf object before issuing an access token to = it. >=20 > Earlier in the section we noted a requirement to prove possession of = the key by using it in DTLS; why is there a separate "association" > requirement? > also, nit: "The AS". >=20 > which case it does not have to be sent. The response also contains > an access token and an "rs_cnf" parameter containing information > about the public key that is used by the resource server. AS MUST >=20 > nit(?): is the "rs_cnf" parameter always mandatory? (Or only when=20 > DTLS-RPK is used for client-RS interactions?) > nit: "The AS" again (and throughought, to a large extent). >=20 > server that C wants to communicate with. AS MUST protect the > integrity of the token. If the access token contains confidential > data, AS MUST also protect the confidentiality of the access token. >=20 > This requirement ("protect the integrity of the token") feels a little = underspecified, as it doesn't say protection over what workflow or who = will verify the integrity (the RS). >=20 > C MUST ascertain that the access token response belongs to a = certain > previously sent access token request, as the request may specify = the > resource server with which C wants to communicate. >=20 > nit: I recomment rewording "belongs to", perhaps as "corresponds to". > DTLS can provide this guarantee when configured to do so, though it is = not a guaranteed property from DTLS. >=20 > We'll probably get some grief about the "access_token" contents in the = example not being valid CBOR, due to the parenthetical comment. We = could probably put a note in the preface that the value is truncated for = readability. Also, nit: "the client's" with article and apostrophe. >=20 > Section 3.2.1 >=20 > Before the client initiates the DTLS handshake with the resource > server, C MUST send a "POST" request containing the new access = token > to the authz-info resource hosted by the resource server. After = the > client >=20 > nit: we don't require single-use tokens, so "new" is probably = overkill; just "its access token" should suffice. > nit: formatting issue with spurious line break here. >=20 > server. To use the RawPublicKey mode, the client MUST specify the > public key that AS defined in the "cnf" field of the access token > response in the SubjectPublicKeyInfo structure in the DTLS = handshake > as specified in [RFC7250]. >=20 > IIRC the access token response does not have to include a "cnf" field = (e.g., if the AS accepts the req_cnf from the request), so "defined in = the field of the response" doesn't seem like quite the right wording. >=20 > An implementation that supports the RPK mode of this profile MUST = at > least support the ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 >=20 > I understand that making the full-width-tag ciphersuite MTI would = exclude some devices, though it feels like some recommendation to use = the full-length tag when possible would be appropriate. That said, I do = see that RFC 7252 makes no such remark, and thus consistency would have = us not say anything either. >=20 > [RFC7251] with the ed25519 curve (cf. [RFC8032], [RFC8422]). >=20 > Just to be clear: ed25519 is an ECDSA algorithm; the corresponding = ECDHE operation is called x25519, and both algorithms make use of the = elliptical curve known as curve25519. Since we are using both ECDHE and = ECDSA, it's probably simplest to just refer to "curve25519", though = mentioning both ed25519 and x25519 would also work. >=20 > RS MUST check if the access token is still valid, if RS is the > intended destination, i.e., the audience, of the token, and if the > token was issued by an authorized AS. The access token is >=20 > nit: "i.e., the audience" is in effect a parenthetical, so using = commas to offset it inside a comma-separated list is potentially = confusing; I'd suggest using actual parentheses instead of commas around = it. >=20 > reference to this key. If the authorization server has no certain > knowledge that the Client's key is already known to the resource > server, the Client's public key MUST be included in the access > token's "cnf" parameter. If CBOR web tokens [RFC8392] are used as > recommended in [I-D.ietf-ace-oauth-authz], keys MUST be encoded as > specified in [I-D.ietf-ace-cwt-proof-of-possession]. RS MUST use=20 > the >=20 > Is talking about """the access token's "cnf" parameter" consistent = with allowing the use of non-CWT (non-JWT) token formats? >=20 > keying material in the handshake that AS specified in the rs_cnf > parameter in the access token. Thus, the handshake only finishes = if > C and RS are able to use their respective keying material. >=20 > I suggest being explicit about "the DTLS handshake with the client", = perhaps as "MUST use in the DLTS handshake with the client the keying = material that the AS specified in the rs_cnf parameter in the access = token". The same caveat about "parameter in the access token" > applies here, though I guess there is an additional complication for = "rs_cnf" in that it's an token response parameter but I don't remember = that we say a huge amount about it also being included in the token = itself -- the token response is directed to the client but the token is = directed to the RS. >=20 > Section 3.3 >=20 > token. AS MUST check if the identifier refers to a symmetric key > that was previously generated by AS as a shared secret for the > communication between this client and the resource server. >=20 > "What does the AS do if this check fails?" >=20 > The authorization server MUST determine the authorization rules for > the C it communicates with as defined by RO and generate the access >=20 > nit: it's surprising to see "authorization server" spelled out in the = same sentence as "C" and "RO" (which, incidentally, we don't seem to use = in abbreviation form anywhere other than where we define it). >=20 > wants to communicate with. Also, AS MUST protect the integrity of > the access token. If the token contains confidential data such as > the symmetric key, the confidentiality of the token MUST also be > protected. Depending on the requested token type and algorithm in >=20 > (same comment about "protect the integrity" or "protect" as for the=20 > RPK > case.) >=20 > that is to be used between C and the resource server. The access > token MUST be bound to the same symmetric key by means of the cnf > claim. >=20 > Now we call it a "claim" rather than a "token parameter", but this = again seems to be implicitly assuming CWT/JWT for tokens. > (Also, this "MUST" seems like something that the framework should=20 > guarantee and not a new requirement that the DTLS profile imposes.) >=20 > Figure 5: Example Access Token Request, symmetric PoP-key >=20 > Maybe we could include "(implicit)" in the caption, since symmetric = PoP key is the default. >=20 > An example access token response is illustrated in Figure 6. In=20 > this >=20 > Is it accurate to say "A corresponding example access token response"? > It's nice to the reader if we can tie the examples together like that. >=20 > Is the "Max-Age" usage in Figure 6 typical? (Also, similar comment=20 > about having the parenthetical comment in the example body vs.=20 > preface.) >=20 > token_type : pop, >=20 > Didn't we switch this to being capitalized as "PoP"? >=20 > "COSE_Encrypt0" structure. The AS MUST use the keying material > shared with the RS to encrypt the token. >=20 > nit: I suggest s/shared with/it shares with/ >=20 > We should probably say something about why the kid in Figure 7 is = different from the one in Figure 6. >=20 > 4.00 Bad Request > Content-Format: application/ace+cbor > Payload: > { > error : invalid_request > } >=20 > Figure 8: Example Access Token Response With Reject >=20 > RFC 6749's description of "invalid_request" seems to imply that it's = mostly about malformed requests, as opposed to the AS deciding that the = client is not authorized for any access to the requested resource (which = is maybe what's implied by the previous paragraph). This is not = necessarily a problem, but perhaps we could make the text and example = more consistent. >=20 > The method for how the resource server determines the symmetric key > from an access token containing only a key identifier is = application > specific, the remainder of this section provides one example. >=20 > nit: hyphenate "application-specific", and this is a comma splice. >=20 > resource server. This key needs to be securely stored and = processed > in the same way as the key used to protect the communication = between > AS and RS. >=20 > nit: is this better as "processed" or "protected"? >=20 > The fields in the context information "COSE_KDF_Context" > (Section 11.2 of [RFC8152]) have the following values: >=20 > o AlgorithmID =3D "ACE-CoAP-DTLS-key-derivation" >=20 > RFC 8152 says that these AlgorithmID values come from the COSE = Algorithms registry, which this does not (unless we register it there, = which we don't currently). Also, since the output is used directly for = DTLS PSK, I don't think the "key-derivation" portion is needed. >=20 > o PartyUInfo =3D PartyVInfo =3D ( null, null, null ) >=20 > (8152 seems to prefer "nil" over "null".) >=20 > o keyDataLength needs to be defined by the application >=20 > o protected MUST be a zero length bstr >=20 > o other is a zero length bstr >=20 > (These three are all members of the "SuppPubInfo" field, which is not=20 > very clear from how we include them in the same list as top-level > fields.) >=20 > Section 3.3.1 >=20 > When a client receives an access token response from an = authorization > server, C MUST ascertain that the access token response belongs to = a > certain previously sent access token request, as the request may > specify the resource server with which C wants to communicate. >=20 > (Same bit about "belongs to".) >=20 > If a resource server receives a ClientKeyExchange message that > contains a "psk_identity" with a length greater zero, it uses the > contents as index for its key store (i.e., treat the contents as=20 > key >=20 > (This is not DTLS 1.3-compatible.) > nits: "greater than", "as an index", "as a key identifier" >=20 > identifier). The resource server MUST check if it has one or more > access tokens that are associated with the specified key. >=20 > I don't understand this sentence -- isn't the access token the precise = contents of the "psk_identity" field, so that there would be a key = associated with the access token, not the other way around? >=20 > If no key with a matching identifier is found, the resource server > MAY process the contents of the "psk_identity" field as access=20 > token >=20 > Similarly here, the causality feels reversed. >=20 > continuing the DTLS handshake. If the contents of the = "psk_identity" > do not yield a valid access token for the requesting client, the = DTLS > session setup is terminated with an "illegal_parameter" DTLS alert > message. >=20 > I think "the RS aborts the DTLS handshake with an 'illegal_parameter' = alert" > would be more conventional phrasing. >=20 > Note2: According to [RFC7252], CoAP implementations MUST support = the > ciphersuite TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]. A client is > therefore expected to offer at least this ciphersuite to the > resource server. >=20 > Do we want to say anything about the (EC)DHE variants? Short-lived = access tokens with the AS generating new symmetric keys can provide = similar forward-secrecy properties to using DHE, but there is in general = a trend in the IETF towards defaulting to providing forward secrecy in = key exchanges. >=20 > When RS receives an access token, RS MUST check if the access token > is still valid, if RS is the intended destination, i.e., the = audience > of the token, and if the token was issued by an authorized AS. =20 > This >=20 > As above, "i.e., the audience of the token" would probably be better = when offset in parentheses than by commas. >=20 > While the client can retrieve the shared secret from the contents = of > the "cnf" parameter in the AS-to-Client response, the resource = server > uses the information contained in the "cnf" claim of the access = token > to determine the actual secret when no explicit "kid" was provided = in > the "psk_identity" field. If key derivation is used, the RS uses = the > "COSE_KDF_Context" information as described above. >=20 > "psk_identity" is a field in ClientKeyExchange, and we say that its = contents are the raw access token for our usage. It does not have a = direct COSE structure for this talk of "kid" to make much sense without = further explanation. >=20 > Section 3.4 >=20 > We may get some requests for a more explicit definition of what the = "authorization information" tied to a client is. >=20 > Once a DTLS channel has been established as described in Section = 3.2 > and Section 3.3, respectively, the client is authorized to access >=20 > nit: I think "or" is more appropriate to join the sections listed, as = only one is applicable to a given connection. >=20 > With the successful establishment of the DTLS channel, C and RS = have > proven that they can use their respective keying material. An = access > token that is bound to the client's keying material is associated > with the channel. Any request that the resource server receives on > this channel MUST be checked against these authorization rules. RS >=20 > nit: I'd s/these/the following/ >=20 > MUST check for every request if the access token is still valid. > Incoming CoAP requests that are not authorized with respect to any > access token that is associated with the client MUST be rejected by > the resource server with 4.01 response as described in Section = 5.1.1 > of [I-D.ietf-ace-oauth-authz]. >=20 > "any access token" implies there might be more than one, though I seem = to recall discussion of updated tokens overwriting any previous one, so = that only one token per client is active at any given time. What did we = end up settling on? >=20 > Also, the referenced framework Section 5.1.1 does not actually mandate = the 4.01 response code. >=20 > The resource server SHOULD treat an incoming CoAP request as > authorized if the following holds: >=20 > We could say more about this "SHOULD" (or change the way we discuss=20 > it) > -- is it the minimum baseline of checks and additional checks may be = applied, or do some of them not apply in some cases, or ...? >=20 > Incoming CoAP requests received on a secure DTLS channel that are = not > thus authorized MUST be rejected according to Section 5.8.2 of > [I-D.ietf-ace-oauth-authz] >=20 > We may also get some questions asking about what the difference is = between the "not authorized with respect to any access token" in the = previous quoted snippet" and "not thus authorized" in this quoted = snippet. >=20 > The client cannot always know a priori if an Authorized Resource > Request will succeed. It MUST check the validity of its keying > material before sending a request or processing a response. If the >=20 > What does "check the validity of its keying material" mean? >=20 > client repeatedly gets error responses containing AS Creation Hints > (cf. Section 5.1.2 of [I-D.ietf-ace-oauth-authz] as response to = its > requests, it SHOULD request a new access token from the = authorization > server in order to continue communication with the resource server. >=20 > Why should this only be done in the case of *repeatedly* getting such = error responses; I thought the idea of the AS Request Creation Hints was = to take immediate effect. > (Also, nit: s/AS Creation Hints/AS Request Creation Hints/.) >=20 > Section 4 >=20 > The client can update the authorization information stored at the > resource server at any time without changing an established DTLS > session. To do so, the Client requests a new access token from the > authorization server for the intended action on the respective > resource and uploads this access token to the authz-info resource = on > the resource server. >=20 > I suggest adding another sentence similar to "Because ACE tokens are = proof-of-possession tokens, the updated authorization information only = takes immediate effect if such proof has already been provided, e.g., if = the PoP key associated with the new token is the same as the one = currently in use." This is further detailed in the following = paragraphs, but not stated concretely as a key principle. >=20 > Section 5 >=20 > DTLS sessions that have been established in accordance with this > profile are always tied to a specific access token. As this token >=20 > Doesn't the dynamic authorization update mechanism allow that token to = be swapped out during the lifetime of the connection? > Also, as a terminology point, I think "DTLS association" is more = appropriate than "DTLS session" for what we describe, since the token is = is tied to the client and consulted at the start of the handshake, as = opposed to being a property of the DTLS session and carried across = resumptions. >=20 > may become invalid at any time (e.g. because it has expired), the > session may become useless at some point. A resource server > therefore MUST terminate existing DTLS sessions after the access > token for this session has been deleted. >=20 > I assume that using "been deleted" vs. "has expired" is a deliberate = choice? If we don't say anything else about when to delete tokens, it = doesn't post much of a requirement, though. >=20 > Section 6 >=20 > endpoint. The use of CoAP and DTLS for this communication is > RECOMMENDED in this profile, other protocols (such as HTTP and TLS = or > CoAP and OSCORE) MAY be used instead. >=20 > nit: comma splice > Also, we could potentially refer to the OSCORE profile document here = (informatively). >=20 > If other means of securing the communication with the AS are used, > the security protocol MUST fulfill the communication security > requirements in Section 6.2 of [I-D.ietf-ace-oauth-authz]. >=20 > I suggest phrasing more like "the communication security requirements = from Section 6.2 of [I-D.ietf-ace-oauth-authz] remain applicable", since = there's no need to add another MUST to the ones already in the framework = document. >=20 > Section 7 >=20 > I have a few suggestions for potential additions to this section as = well as comments on the existing contents. >=20 > We might consider adding a brief note about the use of 8-byte = authentication tags in DTLS ciphers and how that affects the risk = profile. >=20 > The use of "live" authorization upgrades on an existing DTLS = connection by posting a new token to the authz-info endpoint does not = provide much guarantee about the order in which operations occur (and = thus which authorization info is used to process a given client = request), especially in the face of an attacker that can delay and = reorder packets. This does not necessarily mean that we should not = bother to define that mechanism, but we should point out that there is = only a weak ordering property provided, note that other mechanisms = should be used when strict serialization is important, and caution that = when the later-issued token contains a reduction in authorization from = the initial token, it is impossible to guarantee that the reduction in = authorization will take effect prior to the expiration of the original = token. >=20 > We rely heavily on the AS to accurately provide binding of raw key=20 > material to authorization information and endpoint identinty; I think=20 > this is a stronger reliance than just that implied by the core=20 > architecture, and so might merit a mention here. (This relates to all = > the checks about "MUST check that [client/...] is associated with=20 > [RPK/PSK]" that appear throughout the document.) >=20 > I'd also suggest reiterating all the places where we rely on = out-of-band configuration, as there's always a risk of such = configuration becoming stale (or getting attacked directly). >=20 > I'd consider reiterating that when the KDF scheme is in use between RS = and AS, that kid uniqueness is paramount, as using the same kid for = multiple clients and the same RS would have potentially disasterous = consequences in that case. >=20 > Similarly (though this is inherent to symmetric PoP and may not=20 > actually need reiterating), when we use symmetric PSKs for PoP, they=20 > lose almost all value if any given PSK is known to more than one=20 > client or RS. (The secdir review on the framework has us putting in=20 > MUST-level requirements to not share further than that, so it seems=20 > pretty reasonable to not duplicate that warning here.) >=20 > This document specifies a profile for the Authentication and > Authorization for Constrained Environments (ACE) framework > [I-D.ietf-ace-oauth-authz]. As it follows this framework's general > approach, the general security considerations from section 6 also > apply to this profile. >=20 > (The HTMLized link will only do the right thing if you use the=20 > redundant "section 6 of [I-D.ietf-ace-oauth-authz]".) >=20 > The use of multiple access tokens for a single client increases the > strain on the resource server as it must consider every access = token > and calculate the actual permissions of the client. Also, tokens = may > contradict each other which may lead the server to enforce wrong > permissions. If one of the access tokens expires earlier than > others, the resulting permissions may offer insufficient = protection. > Developers SHOULD avoid using multiple access tokens for a client. >=20 > I think I touched on this above; did we want to make a stronger = statement about "only one active token per client"? >=20 > Section 8 >=20 > information as possible in an unencrypted response. When a DTLS > session between the client and the resource server already exists, > more detailed information MAY be included with an error response to > provide the client with sufficient information to react on that > particular error. >=20 > I'd suggest adding a caveat like "an authenticated client" or "a known = client", since DTLS itself does not guarantee that the client is not an = attacker. >=20 > Section 9 >=20 > Profile ID: 1 >=20 > I think this has to be merely a "suggested value", as IANA will = control the actual allocations, in the absence of a reservation of this = value in the framework document. >=20 > Section 10.1 >=20 > We don't currently reference RFC 7925 in any way that would require it = to be a normative reference. We probably should, though -- somehow pull = in that we require/recommend conformance with that profile of DTLS. >=20 > Section 10.2 >=20 > I think RFCs 7250, 7251, and 8422 need to be normative. >=20 > Thanks, >=20 > Ben >=20 From nobody Thu Jan 9 13:22:18 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA47712080F; Thu, 9 Jan 2020 13:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJgDAMwu-RHN; Thu, 9 Jan 2020 13:22:14 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81BF4120807; Thu, 9 Jan 2020 13:22:14 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 009LLii5018214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 9 Jan 2020 16:21:46 -0500 Date: Thu, 9 Jan 2020 13:21:43 -0800 From: Benjamin Kaduk To: Jim Schaad Cc: "'Olaf Bergmann'" , draft-ietf-ace-dtls-authorize.all@ietf.org, ace@ietf.org Message-ID: <20200109212143.GH57294@kduck.mit.edu> References: <20200102234020.GI35479@kduck.mit.edu> <014601d5c2b8$9947acc0$cbd70640$@augustcellars.com> <878smkrjg0.fsf@wangari> <000801d5c4bc$cf418110$6dc48330$@augustcellars.com> <87o8vclvaf.fsf@wangari> <20200109201700.GF57294@kduck.mit.edu> <00b801d5c72e$c6dd42b0$5497c810$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00b801d5c72e$c6dd42b0$5497c810$@augustcellars.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 21:22:17 -0000 On Thu, Jan 09, 2020 at 12:52:56PM -0800, Jim Schaad wrote: > > > -----Original Message----- > From: Benjamin Kaduk > Sent: Thursday, January 9, 2020 12:17 PM > To: Olaf Bergmann > Cc: Jim Schaad ; ace@ietf.org; > draft-ietf-ace-dtls-authorize.all@ietf.org > Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 > > On Thu, Jan 09, 2020 at 12:32:40PM +0100, Olaf Bergmann wrote: > > Hi Jim, > > > > Jim Schaad writes: > > > > > -----Original Message----- > > > From: Ace On Behalf Of Olaf Bergmann > > > Sent: Monday, January 6, 2020 2:03 AM > > > To: Jim Schaad > > > Cc: ace@ietf.org; 'Benjamin Kaduk' ; > > > draft-ietf-ace-dtls-authorize.all@ietf.org > > > Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 > > > > > > Jim, > > > > > > Jim Schaad writes: > > > > > > [Ben's review] > > >> We also are potentially in violation of the framework's requirements > with respect to the independent selection of profiles for client/AS and > client/RS interactions -- at present, when DTLS+RPK is used for client/RS, > we require that DTLS+RPK is also used for client/AS, in order to prove > possession of the key. We could perhaps weasel our way out by saying that > the framework's requirement applies at the profile granularity, and with > symmetric PSK we can be fully independent, but we still need to say > something about this property and the interaction with the framework's > requirements. > > >> > > >> [JLS] I am missing where it is saying this. Can you give a pointer? > I don't believe that the POP of the RPK is required at the time that the > token is obtained. > > > > > > The problem is that AS must bind the Access Token to the RPK that the > Client has presented, and the Client must use the very same RPK to establish > the DTLS channel with RS. Otherwise, RS cannot be sure that AS has issued > the Token to the same entity that is currently communicating with RS. > > > > > > [JLS] What if I do the following sequence of events: > > > 1. The AS is configured with RPK1 for the client and the client is > configured with RPK2 for the AS. > > > 2. The client and the AS run some type of POP algorithm, not currently > specified, to configure RPK3 into the AS for a second RPK to work with some > set of audiences (AUD1). > > > 3. The client then uses RPK1 to authenticate to the AS and asks for a > new token for AUD1 and provides (explicitly or implicitly RPK3). The AS > knows that it is tied to the client due to what happened in step 2. The AS > then creates a new token for AUD1 which contains RPK3 for the client (and > RPK4 for the RS) and returns it. > > > > > > The AS does a current POP for RPK1 when the token is being asked for. > > > The AS did a POP for RPK3 when it was placed into the system. > > > The AS has not done a POP for RPK4 - that was simply configured without > that step ever being done. The ACE framework has no ability for the AS to > do the POP on RPK4 and ensure that it current. The client would do a POP > when the TLS session is created but has to rely on the AS that it is for the > correct RS. > > > > > > Note that the client can never generate a brand new RPK9 and send it to > the AS in the token request because the AS will never have seen this before > and would need to run the POP algorithm of step 2 in order to assure that it > is bound to the correct client and not pulled out of thin air. RPK9 could > not be used to authenticate the token request because the AS has no idea > what client it is tied to. > > > > okay, I see you have a valid point here. I will try to come up with > > some text that says that the AS must ensure that (in your scenario) > > RPK1 and > > RPK3 are bound to the same entity. > > Jim's proposal seems broadly reasonable (though I think in general there > needs to be some AS contributory nature in order to get proof of current > possession of RPK3 at the time of (2). I think I would phrase it as "in > possession of the same entity" rather than "bound to the same entity", > though. > > [JLS] If I was to write this out as a real protocol, it would end up > something along the lines of Sign(RPK1, Sign(RPK3, RPK1 || RPK3 || AS > Nonce || Client Nonce )) so that we know that both keys are in the > possession of a single entity (or a cabal collaborating) and it is current > to the run of the POP protocol. With a fixed protocol/context string to indicate the intent of what's being signed, of course :) I am too distracted to do a proper analysis right now but seem to recall that usually an indication of "both parties/keys agree to " involves three signatures, so that each party certifies the signature of the other over the operation (in addition to the operation itself). -Ben From nobody Thu Jan 9 13:43:26 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6936F120803; Thu, 9 Jan 2020 13:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTVTUTdgkKVp; Thu, 9 Jan 2020 13:43:21 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FB3912021C; Thu, 9 Jan 2020 13:43:20 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 9 Jan 2020 13:43:13 -0800 From: Jim Schaad To: 'Benjamin Kaduk' CC: 'Olaf Bergmann' , , References: <20200102234020.GI35479@kduck.mit.edu> <014601d5c2b8$9947acc0$cbd70640$@augustcellars.com> <878smkrjg0.fsf@wangari> <000801d5c4bc$cf418110$6dc48330$@augustcellars.com> <87o8vclvaf.fsf@wangari> <20200109201700.GF57294@kduck.mit.edu> <00b801d5c72e$c6dd42b0$5497c810$@augustcellars.com> <20200109212143.GH57294@kduck.mit.edu> In-Reply-To: <20200109212143.GH57294@kduck.mit.edu> Date: Thu, 9 Jan 2020 13:43:11 -0800 Message-ID: <00c201d5c735$cbeae260$63c0a720$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHGCRF5nmwiv9SPGwzqJ8qbQfLFcAHlgxMZAtepCeUBXvgPxwIAJCZJAqEcdxYBj/t2QQJBefWfp43icvA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 21:43:24 -0000 -----Original Message----- From: Benjamin Kaduk Sent: Thursday, January 9, 2020 1:22 PM To: Jim Schaad Cc: 'Olaf Bergmann' ; draft-ietf-ace-dtls-authorize.all@ietf.org; ace@ietf.org Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 On Thu, Jan 09, 2020 at 12:52:56PM -0800, Jim Schaad wrote: > > > -----Original Message----- > From: Benjamin Kaduk > Sent: Thursday, January 9, 2020 12:17 PM > To: Olaf Bergmann > Cc: Jim Schaad ; ace@ietf.org; > draft-ietf-ace-dtls-authorize.all@ietf.org > Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 > > On Thu, Jan 09, 2020 at 12:32:40PM +0100, Olaf Bergmann wrote: > > Hi Jim, > > > > Jim Schaad writes: > > > > > -----Original Message----- > > > From: Ace On Behalf Of Olaf Bergmann > > > Sent: Monday, January 6, 2020 2:03 AM > > > To: Jim Schaad > > > Cc: ace@ietf.org; 'Benjamin Kaduk' ; > > > draft-ietf-ace-dtls-authorize.all@ietf.org > > > Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 > > > > > > Jim, > > > > > > Jim Schaad writes: > > > > > > [Ben's review] > > >> We also are potentially in violation of the framework's > > >> requirements > with respect to the independent selection of profiles for client/AS > and client/RS interactions -- at present, when DTLS+RPK is used for > client/RS, we require that DTLS+RPK is also used for client/AS, in > order to prove possession of the key. We could perhaps weasel our way > out by saying that the framework's requirement applies at the profile > granularity, and with symmetric PSK we can be fully independent, but > we still need to say something about this property and the interaction > with the framework's requirements. > > >> > > >> [JLS] I am missing where it is saying this. Can you give a pointer? > I don't believe that the POP of the RPK is required at the time that > the token is obtained. > > > > > > The problem is that AS must bind the Access Token to the RPK that > > > the > Client has presented, and the Client must use the very same RPK to > establish the DTLS channel with RS. Otherwise, RS cannot be sure that > AS has issued the Token to the same entity that is currently communicating with RS. > > > > > > [JLS] What if I do the following sequence of events: > > > 1. The AS is configured with RPK1 for the client and the client > > > is > configured with RPK2 for the AS. > > > 2. The client and the AS run some type of POP algorithm, not > > > currently > specified, to configure RPK3 into the AS for a second RPK to work with > some set of audiences (AUD1). > > > 3. The client then uses RPK1 to authenticate to the AS and asks > > > for a > new token for AUD1 and provides (explicitly or implicitly RPK3). The > AS knows that it is tied to the client due to what happened in step 2. > The AS then creates a new token for AUD1 which contains RPK3 for the > client (and > RPK4 for the RS) and returns it. > > > > > > The AS does a current POP for RPK1 when the token is being asked for. > > > The AS did a POP for RPK3 when it was placed into the system. > > > The AS has not done a POP for RPK4 - that was simply configured > > > without > that step ever being done. The ACE framework has no ability for the > AS to do the POP on RPK4 and ensure that it current. The client would > do a POP when the TLS session is created but has to rely on the AS > that it is for the correct RS. > > > > > > Note that the client can never generate a brand new RPK9 and send > > > it to > the AS in the token request because the AS will never have seen this > before and would need to run the POP algorithm of step 2 in order to > assure that it is bound to the correct client and not pulled out of > thin air. RPK9 could not be used to authenticate the token request > because the AS has no idea what client it is tied to. > > > > okay, I see you have a valid point here. I will try to come up with > > some text that says that the AS must ensure that (in your scenario) > > RPK1 and > > RPK3 are bound to the same entity. > > Jim's proposal seems broadly reasonable (though I think in general > there needs to be some AS contributory nature in order to get proof of > current possession of RPK3 at the time of (2). I think I would phrase > it as "in possession of the same entity" rather than "bound to the > same entity", though. > > [JLS] If I was to write this out as a real protocol, it would end up > something along the lines of Sign(RPK1, Sign(RPK3, RPK1 || RPK3 || > AS Nonce || Client Nonce )) so that we know that both keys are in the > possession of a single entity (or a cabal collaborating) and it is > current to the run of the POP protocol. With a fixed protocol/context string to indicate the intent of what's being signed, of course :) I am too distracted to do a proper analysis right now but seem to recall that usually an indication of "both parties/keys agree to " involves three signatures, so that each party certifies the signature of the other over the operation (in addition to the operation itself). [JLS] Yea I think you are right - I would need to go read CMC and make sure that I got everything right as I spent about 2 years doing the analysis there -Ben From nobody Fri Jan 10 07:33:09 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29BB912009E for ; Fri, 10 Jan 2020 07:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GD0DIEJ5UAl5 for ; Fri, 10 Jan 2020 07:33:02 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130051.outbound.protection.outlook.com [40.107.13.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA8D2120026 for ; Fri, 10 Jan 2020 07:33:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ki6eNaWq6fNVACzLwH9iDST9diy2T7NAj/2vhioym0PjdfJDDppPlSgjrstiaSRoBHiYS2W39W/KrYdr1gKLq25ltHlBGkLc63oeD7TPJjxxAq1UoG5k/Xq/BOMXdkbw0bgVnsKjY0AiHQuU1A7M8IPDLQYSx6Ibj2sc4DkatsRERooVd6MdjOur/UlKQa1Et3672omvQcZ35fxx1GLvRRg/aSSYUYESofIVDukWfDU2nJK/7VKgk1tD7JCfqFutMnmPQlEmtN0f6ouHx5vYvY/6aaepluJzJNGMzFo27noBrYziAW3eHmTUI1/2NaYKv05VRZRKXHJAvvK1XOnFuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UHZiDNSWdAVnu4uOoGOGkWIzRW40tzc5XLAplxgIBuo=; b=na75+/spqKoZBXVOwurwel5vVZULjADqvuc7Wpa35/D1BZj+nF2+K/lWAEwj00yBnVe2NF7pZ5sN8gKLBhltCgw+pp7fY46djtF9RbqVUdYyV6T5xtMXokHdhu+ReeQqlXTFiONv+or9XdDs7VpTUVx0OTAmTHeB4h1HAmlfk+dRu9Aha2uhx1qY81TjF7cru1TONRFs6P+ix0PP/H6dNWaJuRkHpb3pGZWfmT/kTx+wIojnC9bS/Wh/t61SDoMg14AkD8srxgcp6jMbRwf7PoFR35mpsvBHtVVJFEJRsfd+dNLsqoocsZb+MsnpsQGl5kPFT2ZyZ46fbzPuxtKd5Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UHZiDNSWdAVnu4uOoGOGkWIzRW40tzc5XLAplxgIBuo=; b=dPFmvq17lQfxABuijWTCI0nryDj8gwoeIybKbFitOfyuR9Aog3aJrHk5yvRtLvhlM3ioXN+S/uqtEV5hrMihrUJkVSXD6ewntfp59E2mLj2ycbzCNYY61+/GOz9/dcrtzeUafs2ghm+asddhf7mpMMULtDKUBEu4JXGYR+IPZYU= Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (10.165.195.159) by VI1P189MB0415.EURP189.PROD.OUTLOOK.COM (10.165.190.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.12; Fri, 10 Jan 2020 15:32:58 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::3485:ce83:891b:469]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::3485:ce83:891b:469%4]) with mapi id 15.20.2623.013; Fri, 10 Jan 2020 15:32:58 +0000 Received: from [10.8.1.17] (37.120.141.36) by AM0PR0102CA0035.eurprd01.prod.exchangelabs.com (2603:10a6:208:14::48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.8 via Frontend Transport; Fri, 10 Jan 2020 15:32:58 +0000 From: Marco Tiloca To: Ace Wg Thread-Topic: Comments on draft-ietf-ace-pubsub-profile-00 Thread-Index: AQHVx8s8hSnXuthea0qcDZSa3WhTDA== Date: Fri, 10 Jan 2020 15:32:58 +0000 Message-ID: <372a4f53-9e7e-008c-ce70-5e97ace4f953@ri.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-clientproxiedby: AM0PR0102CA0035.eurprd01.prod.exchangelabs.com (2603:10a6:208:14::48) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) authentication-results: spf=none (sender IP is ) smtp.mailfrom=marco.tiloca@ri.se; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [37.120.141.36] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f0ea6924-f5fb-4580-f680-08d795e25eef x-ms-traffictypediagnostic: VI1P189MB0415: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02788FF38E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(346002)(136003)(366004)(396003)(189003)(199004)(44832011)(316002)(16576012)(36756003)(5660300002)(31686004)(8676002)(2616005)(66476007)(86362001)(478600001)(81166006)(31696002)(66616009)(66556008)(956004)(66946007)(66446008)(8936002)(64756008)(966005)(186003)(6486002)(66574012)(81156014)(16526019)(71200400001)(2906002)(26005)(52116002)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P189MB0415; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ri.se does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: A52sESht6amatbyMAC8z0lGjXZY7UCvLQo6fZBY9nD+nCU4h33KTtzI5pVnSeJODrn2Ng9Y/n4woI8hOslTwfS93fDUNCaxDQuJqnucr1Xha+bwVqO25Bvkb2J4SvjD9SFWYH9rNlsqYPTcUaDTjCDtqpZUc7f0SMfIN4JounFl9yqIVrfP6kiHD7u/TRWX2lg4UaWj0TxJpEcikIvQk8HGr/fFIahFwYm7dsL5O2nvMzCAbXipKdo1ghv2ZxyW3zYcHkudzfDSFzQdiyUvqJgUqZIhUsujKq/d5R6m2xqkNvtCiAJWRm/tIzZN0M5vzpaCTI0m4KC8+B+dd9AOhxnil8r1vWs0Y4fxBhur/vpxskPB15mgrD8hXAzr8wZWUuzhSBjz/N4PupI4Z8JIZDQQeAqLOMfp9ybGVFBhuhcc15YiaoSTdZ9auL1hoOyBfmOYa+RmzsT0+b2uRut9BqOkm4jORmz/qu9h70dmbVicXiD6x03GFQqV2dlSog7BUdNGeRLlSa5Ax3F3w08mjUA== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="05pb8WwI62siv49hNlEzhKh5lEUjZcTm6" MIME-Version: 1.0 X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: f0ea6924-f5fb-4580-f680-08d795e25eef X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2020 15:32:58.6135 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: sYSbkPkn1ZJmA3+Xz7fDW7fS60iENSrLNJRB4GdkQ7Er2THCqpKnpP4fCuJS2asdelwHZx6NQrSql1z5gJgBuA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0415 Archived-At: Subject: [Ace] Comments on draft-ietf-ace-pubsub-profile-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 15:33:08 -0000 --05pb8WwI62siv49hNlEzhKh5lEUjZcTm6 Content-Type: multipart/mixed; boundary="YMCoibcAEuzL60nrXL6BZhvfhJIkNtX0v" --YMCoibcAEuzL60nrXL6BZhvfhJIkNtX0v Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi, Please, see below a couple of comments and thoughts on this profile. 1. In Section 7, the second paragraph says "critical that only authorized Publishers can publish", i.e. it points at an authorization aspect. However, the sentence continues with opening for a purely symmetric key-based solution, in case source-authentication is not strictly needed and anonymity is desired. I suppose that this paragraph is actually intended to discuss the latter aspect, so it may be better to rephrase it to clarify its focus on source- vs. group- authentication, rather than on authorization to publish. That is, authorization to publish to that topic is still enforced in either case, by AS2 providing the topic-related symmetric key to the publisher. 2. The document needs to define how to construct the AEAD nonce used to protect/verify a published message. Unless only one publisher per topic is admitted, this seems to require to have also a Publisher ID to use for constructing the nonce. Publisher IDs would have to be unique under the same topic, which AS2 is in a position to ensure. A possible way to manage and distribute Publisher IDs can be: a) In the joining request payload (see Figure 5), the publisher provides its own public key in 'client_cred' but without a 'kid'. b) The joining response (see Figure 6) includes a new parameter, specifying a Publisher ID "PID" determined by AS2 and unique within that topic. This is similar to what is done in ace-key-groupcomm-oscore by the Group Manager upon a new member's joining. c) AS2 stores the publisher's public key, adding as its 'kid' field the "PID" from step (b). d) A subscriber learns the Publisher ID "PID", whenever retrieving the public key of that publisher from AS2. e) When publishing a message, the publisher includes its own Publisher ID "PID" received at step (b) above, in the 'kid' of the unprotected field of 'countersign' (see Figure 12). This should still be aligned to what described now in the draft, but entrusting AS2 to manage the 'kid' of public keys as Publisher IDs, so ensuring their uniquess within a topic. Then the actual nonce construction can possibly be along the lines of the one for (Group) OSCORE, see https://tools.ietf.org/html/rfc8613#section-5.2 Best, /Marco --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --YMCoibcAEuzL60nrXL6BZhvfhJIkNtX0v-- --05pb8WwI62siv49hNlEzhKh5lEUjZcTm6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl4YmSQACgkQ7iZktA5Y 2kPqjAgAqRl4kLbcHLbOnTknKdFLzkHyg4lkAVijHLFkUIVxVY8tYbbtku4tpYgA 1fTq8pzdTgGUa+w5AitBN0UMmPTW+NjX4+q1qDRewX5rCVdKP7Z7UZ+EwBHDbEYD NyZU7kwUl33KGfCH2FQkadpSdacz5vufswvzHkKF8EeiQgdvTEtaufVQ8pwDP92S /DSuPtk6U7e3tdXNpkVZmq3t/dXo4qL4ADFp5/FwWaoMkupRbx+bfjAoNZLdWIp8 cw+X7tKTuK3bKcldSuH5j4qWHeBCZF98IZ7VVg8wt+LZc5EdzB1NSW8sOEftbZlt LGT6kyHcRbUTj3RMKuQX6VgQlF3Ayg== =K+3l -----END PGP SIGNATURE----- --05pb8WwI62siv49hNlEzhKh5lEUjZcTm6-- From nobody Fri Jan 10 12:16:38 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCDD120052 for ; Fri, 10 Jan 2020 12:16:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6et-iaWIzgl for ; Fri, 10 Jan 2020 12:16:34 -0800 (PST) Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A9351200DB for ; Fri, 10 Jan 2020 12:16:33 -0800 (PST) Received: by mail-lj1-x241.google.com with SMTP id j1so3413095lja.2 for ; Fri, 10 Jan 2020 12:16:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cSkYyVX1FsV5mHagG2cEgfRLsc7a00l4yr6Es6a3yNI=; b=UpxNAhBB1pXqW/xUqY/r1ZDXRdvKndC0w1dX6Ihp9r9nIM3DqXp6Y8MOPVCJIUu62V b2UnJCoxrIjYdS3ukzpJkFFUMu1u3raTdisXOnpmynSTAV9zHU9HER1mfDPBcunJPODf 1lPJmw6SjT3nPHdGIdowMCHIaHL5lCwfmMc9sxH3VwUMDyRE3XDUqHlhlc8Y078BPfyD veWVzYzyPG15tPYEO7R42UkSb7P4iKrLCqYpfeXzyWa+uCc2nH7ZC9YmpJ8sTLvRAazZ 7/UufqW+zxLWAtASFdxn5b9RmVQ8pFIETcPMSr8o4Iu78ix144QXyFY6NhADu4IuVvoo Llwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cSkYyVX1FsV5mHagG2cEgfRLsc7a00l4yr6Es6a3yNI=; b=ev3+04fdjn10dINX98QhMLI5blZ8wIZ7qK/vBzWNyT4V1rPEC3EL8aUBf+C0RcYBMc dIzUAbAfUmunzNm9XYYOxH7L74DJW+meBY7wI2Xu6AHXROC9Pi4TA2hpEqjcbx4aFzTP Tua3ma8DW/wjLN+JTk2KJgHhbg3bGmm7fwD6NSSi0hsoXaKGC1/KASLWcREtvGkWaRf0 ZeE9N+YwUp5jJOsP3Mug9LxQ5079P8GiCP3KNDHKdiGg/P0IMEM0HSbVm2tWHZ55fU8/ WykZWFKFPfHd9qdfR5bPvOC1YMlJ19Pqlcv1qtk2NnnXdIMm8hUqjUSHJj3/ndPev3DL kqtA== X-Gm-Message-State: APjAAAW2pcFkoVp1H+A/ZBfKR+FAzkywe6wT5AhujoFcJC5oVKv/p0WT 3z/6rQm3jdUQpStFg6At7hUgfdzTbc0uC2milcufpmzBdCNrgJCcZTQ5HTWPPllPshL/ecGUIh5 g8asNtoFCKOU= X-Google-Smtp-Source: APXvYqxBCeG5dJMFLRuEOGIz/IL6IKZo6/ybyOGMOjBeLVkzZNdZjXQYhVQX1uLcsY9xdwRmQWnqlMcp6bAtW5rXbQc= X-Received: by 2002:a2e:94c8:: with SMTP id r8mr3716097ljh.28.1578687391671; Fri, 10 Jan 2020 12:16:31 -0800 (PST) MIME-Version: 1.0 References: <4a5177af-a442-f109-f620-0ae91953eb63@gmx.de> In-Reply-To: From: Brian Campbell Date: Fri, 10 Jan 2020 13:16:05 -0700 Message-ID: To: Ludwig Seitz Cc: Roman Danyliw , oauth-ext-review@ietf.org, Daniel Migault , Jim Schaad , Benjamin Kaduk , "ace@ietf.org" , drafts-lastcall@iana.org Content-Type: multipart/alternative; boundary="000000000000314267059bcecdb3" Archived-At: Subject: Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 20:16:37 -0000 --000000000000314267059bcecdb3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That certainly takes care of the registry conflict problem, thanks. I'm a little confused, however, and uncertain if that changes the syntax in a way that maybe wasn't intended? -09 had: cnf OPTIONAL. This field contains information about the proof-of- possession key that binds the client to the access token. Values of this parameter follow the syntax of the "cnf" claim from section 3.1 of [I-D.ietf-ace-cwt-proof-of-possession]. See Section 5 for additional discussion of the usage of this parameter. while -10 has: Furthermore the AS can use the "cnf" parameter specified in section 9.4 of [I-D.ietf-oauth-mtls] in an introspection response. For CBOR- based interactions the AS MUST use the parameter mapping specified in Figure 5. So in -09 the "cnf" Introspection Response Parameter was the following the syntax of the "cnf" claim from PoP Key Semantics for CWTs [ID.ietf-ace-cwt-proof-of-possession] and in -10 it's following the syntax of PoP Key Semantics for JWTs [RFC7800] transitively via [I-D.ietf-oauth-mtls] reference. I think I understand that the two PoP key semantics documents are conceptually the same or similar. But I don't know that the syntax is the same? Figure 5 is pointed to for mapping between CBOR and JSON but it only has mappings for the main top level parameters. Maybe I just don't get it or am missing something... On Tue, Jan 7, 2020 at 12:46 PM Ludwig Seitz wrote: > On 2019-12-23 22:32, Brian Campbell wrote: > > The OAuth Token Introspection Response registry > > < > https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#= token-introspection-response > > > > already has an entry for "cnf", which makes the first request in > > https://tools.ietf.org/html/draft-ietf-ace-oauth-params-07#section-9.4 > > rather problematic. > > > > OAuth beats us on the finish line again :-( > > I have updated the draft to remove the registration and refer to the > MTLS draft. > > /Ludwig > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000314267059bcecdb3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That certainly takes care of the registry conflict pr= oblem, thanks.

I'm a little confused, how= ever, and uncertain if that changes the syntax in a way that maybe wasn'= ;t intended?

-09 had:
=C2=A0 cnf =
=C2=A0 =C2=A0 =C2=A0OPTIONAL.=C2=A0 This field contains information= about the proof-of-
=C2=A0 =C2=A0 =C2=A0possession key that binds= the client to the access token.=C2=A0 Values
=C2=A0 =C2=A0 =C2=A0= of this parameter follow the syntax of the "cnf" claim from =C2=A0 =C2=A0 =C2=A0section 3.1 of [I-D.ietf-ace-cwt-proof-of-possessio= n].=C2=A0 See
=C2=A0 =C2=A0 =C2=A0Section 5 for additional discuss= ion of the usage of this
=C2=A0 =C2=A0 =C2=A0parameter.
=
while -10 has:
=C2=A0 Furthermore the AS can u= se the "cnf" parameter specified in section
=C2=A0 9.4 o= f [I-D.ietf-oauth-mtls] in an introspection response.=C2=A0 For CBOR-
= =C2=A0 based interactions the AS MUST use the parameter mapping specifi= ed in
=C2=A0 Figure 5.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0
So in -09 the "cnf&q= uot; Introspection Response Parameter was the following the syntax of the &= quot;cnf" claim from PoP Key Semantics for CWTs [ID.ietf-ace-cwt-proof= -of-possession] and in -10 it's following the syntax of PoP Key Semanti= cs for JWTs [RFC7800] transitively via [I-D.ietf-oauth-mtls] reference. I t= hink I understand that the two PoP key semantics documents are conceptuall= y the same or similar. But I don't know that the syntax is the same? Figure 5 is pointed to for mapping between CBOR a= nd JSON but it only has mappings for the main top level parameters. Maybe I= just don't get it or am missing something... =C2=A0





=C2=A0 =

On Tue, Jan 7, 2020 at 12:46 PM Ludwig Seitz <ludwig_seitz@gmx.de> wrote:
=
On 2019-12-23 22:32= , Brian Campbell wrote:
> The OAuth Token Introspection Response registry
> <https://www.iana.org/assignments/oauth-parameters/oauth-paramet= ers.xhtml#token-introspection-response>
> already has an entry for "cnf", which makes the first reques= t in
> https://tools.ietf.org/ht= ml/draft-ietf-ace-oauth-params-07#section-9.4
> rather problematic.
>

OAuth beats us on the finish line again :-(

I have updated the draft to remove the registration and refer to the
MTLS draft.

/Ludwig


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000314267059bcecdb3-- From nobody Fri Jan 10 12:57:49 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC5A120119 for ; Fri, 10 Jan 2020 12:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o63UCvd1_-WN for ; Fri, 10 Jan 2020 12:57:44 -0800 (PST) Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B5AD120111 for ; Fri, 10 Jan 2020 12:57:44 -0800 (PST) Received: by mail-lf1-x144.google.com with SMTP id y19so2482538lfl.9 for ; Fri, 10 Jan 2020 12:57:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q21hQZ3N/IvEP7LqEwES+heaN5MTopjHDTcNcSdobwM=; b=A0sMsZVGU49daTIScV4mOss2knBk8aQQ0ef8hL2qTMgAtCnq/xTDp7iZAIZFDzlgUs ahI6ep6kkMPegMaqF3m8x+54Bzz309pU9KuMUXXyltEZ34EBwgvbun3gBm3wA/oIvpcP VOlcQH4NcR+xEyOOfxaDburZCMX6VLbIYD7vM+qN8D77KBhMR9J/FaLIuboPyOl+5O+l pvVvZ2809xU/HVHM6FAF6DxCIN88Ok7D/catre28kk/U6w6Ue8mB+aMKxbfFXZvgI12L KU7h1jK1N4caNNwwCKVbjk5cHbAaTDY58DQdwp7GcV4K/hPdke8E/xxKARD2+VALIeEP 6Hbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q21hQZ3N/IvEP7LqEwES+heaN5MTopjHDTcNcSdobwM=; b=doyJ8oWNYljLaVJJOeF18NL/YHg30d7OxRjkcA398XAICHc243l2IQBWllUKLe5bRR mukvxDnWif1FIxTO1GUu2UVL//3XuIhZm7hRwwhCI6Y5zi2CFLcAEc1bScDdyU6P/n72 6q/8QHE52QIZj5XkcTAop/nKQQ153nF+GUGshPx1/DRaDzY24xWE0kZfJRE0ty+bUX2q vziIjrCAU+Hh0zqMovhSad9/TpwMm+1XeZ9E6ZYsQ2y8kK+idoV7mJDz4cN16ACwX3kJ Qdt19OkIXdMICXEA73aJircnpIdd7NOyvz6D9WRVTpgEsHRRw5j/nnuLVn5+7Qmib3Q/ h1Ew== X-Gm-Message-State: APjAAAVPoCCIKkUMPBTJr8imWLyG6uziDs1hwlXbmMVWlwXJrX31rQix /TxloSsv+W1uiNpy/88fYxHyfbdZfiIsTPPSmpaacoW63ZHBZr54PXyL1OEyMS4FVEpPLjo6XAb JXqCb7tXqnhc= X-Google-Smtp-Source: APXvYqxPH1mFmXXOPMF8ZtoE2ruod1Mf7n88fcl1/d31snKaft+BG9BDfB3ubsHGYMxwdQxHbUFJN3XxtefHqxiNTwE= X-Received: by 2002:ac2:4d04:: with SMTP id r4mr3556056lfi.77.1578689862850; Fri, 10 Jan 2020 12:57:42 -0800 (PST) MIME-Version: 1.0 References: <9c32d171-9a4a-ba71-c989-92a177d9e989@gmx.de> In-Reply-To: From: Brian Campbell Date: Fri, 10 Jan 2020 13:57:16 -0700 Message-ID: To: Ludwig Seitz Cc: jwt-reg-review@ietf.org, Roman Danyliw , Jim Schaad , The IESG , "ace@ietf.org" , drafts-lastcall@iana.org, Benjamin Kaduk Content-Type: multipart/alternative; boundary="0000000000007c7bac059bcf6054" Archived-At: Subject: Re: [Ace] [Jwt-reg-review] Requested review for IANA registration in draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 20:57:48 -0000 --0000000000007c7bac059bcf6054 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm really struggling with understanding what the value of an "ace_profile" claim actually would be in a JWT. A JSON string that's the profile name (though 5.6.4.3 maybe prohibits that)? A JSON number that's an integer matching the CBOR Value? Something else? Is the value of "exi" in a JWT a JSON number? Seems likely but it's something that should probably be made explicit. Also for "exi", the requirement in 5.8.3. to "keep track of the identifiers of tokens containing the "exi" claim that have expired (in order to avoid accepting them again)" seems problematic in that it sounds like it's mandating an unbounded growth of memory use. The draft says that the "cnonce" claim (value) uses binary encoding. What does that mean for JSON based JWT? On Sat, Dec 21, 2019 at 4:35 AM Ludwig Seitz wrote: > Hello JWT registry reviewers, > > the IESG-designated experts for the JWT claims registry have asked me to > send a review request to you about the claims registered here: > > https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-29#section-8.12 > > Thank you in advance for you review comments. > > Regards, > > Ludwig > > _______________________________________________ > Jwt-reg-review mailing list > Jwt-reg-review@ietf.org > https://www.ietf.org/mailman/listinfo/jwt-reg-review > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000007c7bac059bcf6054 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm really struggling with understanding what the= value of an "ace_profile" claim actually would be in a JWT. A JS= ON string that's the profile name (though 5.6.4.3 maybe prohibits that)= ?=C2=A0 A JSON number that's an integer matching the CBOR Value? Someth= ing else?=C2=A0

Is the value of "exi" in= a JWT a JSON number? Seems likely but it's something that should proba= bly be made explicit.

Also for "exi"= ;, the requirement in 5.8.3. to "keep track of the identifiers of toke= ns containing the "exi" claim that have expired (in order to avoi= d accepting them again)" seems problematic in that it sounds like it&#= 39;s mandating an unbounded growth of memory use.

=
The draft says that the "cnonce" claim (value) uses binary e= ncoding. What does that mean for JSON based JWT?

On Sat, Dec 21, = 2019 at 4:35 AM Ludwig Seitz <lud= wig_seitz@gmx.de> wrote:
Hello JWT registry reviewers,

the IESG-designated experts for the JWT claims registry have asked me to send a review request to you about the claims registered here:

https://tools.ietf.org/html/dr= aft-ietf-ace-oauth-authz-29#section-8.12

Thank you in advance for you review comments.

Regards,

Ludwig

_______________________________________________
Jwt-reg-review mailing list
Jwt-reg-review= @ietf.org
https://www.ietf.org/mailman/listinfo/jwt-reg-re= view

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000007c7bac059bcf6054-- From nobody Fri Jan 10 13:12:33 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0270B1200E9 for ; Fri, 10 Jan 2020 13:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6usgwK9pY9j for ; Fri, 10 Jan 2020 13:12:30 -0800 (PST) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B158D12008C for ; Fri, 10 Jan 2020 13:12:29 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id 9so2510932lfq.10 for ; Fri, 10 Jan 2020 13:12:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZrlstIV2pgTIe8IoGLocyuO7JgJ3lLB7wDZhmRUVQfY=; b=NPy8yT0Y67phqIDxjOnqZtfTHmzmbMnKz6178LWhNPo0RmiaqhZkHi6Sb+Z6mIb6eD Zk+gbu43E0yjnvPW72aHnwX2RZDONz6psJHP+Eb161Cv1xs1/kubCFP761arubFKyVeL TB1A2bN7DJse9nOd83SNUrKbi+r3RisKi7tk99CduOIidVk8/7cwQSfbF0enDmORrhnV vg4xifOjfrLonzCrNb3kRq0fmOJxwGUlplF9buVLhyigrdBDaD3VdL98trne361qkHiw 0IYE3UG/6eTha74umYEgqdmxcaRY+NAb3bG9UF24KRJEE2r3T9pBTNI5MlaX+1IKJYoZ EeVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZrlstIV2pgTIe8IoGLocyuO7JgJ3lLB7wDZhmRUVQfY=; b=UtNjpFfbvi2EeImjs6WQheK6hSpGl01osTcc/ctnajfOR2eAX5ZMQdJqHT3fZ9kBX6 lAqhv9/ILUdkqaQ1Vn7vY5pl58YytEX9vKsQhRBA72euyNPNysom+nNkZVCOuk+L7OsH TxrHyI4Q2Y67BoG+1KpBz+WLULsCUBbZ399TdsZSGlWKYLfY3/Q2xD+Y7uHK+ZY6Wk6u jTJ73bqfrfxoaKqRx2n/ALSUMgWmls/Y/HkIutmZ1U+HmRYCYpsqms6ZhA7NlgcghDBK ALGqmBUVbBKbVcvAr9iKDamTrxD61DTf31vNMwN+2Elc+S7c0OPgUzVi8heOrGZwZ0TV FxDw== X-Gm-Message-State: APjAAAWrG+hTiXZL5FnmQfZFEf9j34Qi/vqYDcO4OgjldYVL6foRdZQm G4KPi180yERdWVmqfGN4eKyud8uDUY3prgWR+3zyrCgTjnfD52w6L6xHyltPEoHXjeezdp0fZL9 woUoUa9UE6CI= X-Google-Smtp-Source: APXvYqyQ+nhSPqMQ/N2sPfuKtb5EujijCYX5qpfRAafeBm9RNcwxXWLD7PSU6TtNGIA0m2qsOpojqArHVN4dwCLHKd8= X-Received: by 2002:ac2:44d9:: with SMTP id d25mr3604646lfm.15.1578690747987; Fri, 10 Jan 2020 13:12:27 -0800 (PST) MIME-Version: 1.0 References: <9c32d171-9a4a-ba71-c989-92a177d9e989@gmx.de> In-Reply-To: <9c32d171-9a4a-ba71-c989-92a177d9e989@gmx.de> From: Brian Campbell Date: Fri, 10 Jan 2020 14:12:01 -0700 Message-ID: To: Ludwig Seitz Cc: jwt-reg-review@ietf.org, Roman Danyliw , Jim Schaad , The IESG , "ace@ietf.org" , drafts-lastcall@iana.org, Benjamin Kaduk Content-Type: multipart/alternative; boundary="0000000000003ea6f9059bcf955c" Archived-At: Subject: Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 21:12:32 -0000 --0000000000003ea6f9059bcf955c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That "rs_cnf" claim registration request in 9.1 points to 3.3 which says it has 'the same syntax and semantics as defined in for the "rs_cnf" parameter', which I think is in 4.1. And 4.1 says that the "rs_cnf" values 'follow the syntax of the "cnf" claim from section 3.1 of [I-D.ietf-ace-cwt-proof-of-possession].' Similar to other comments I've made today, I don't follow what that would mean for the value of the claim when it's a JWT. And that seems like something that's important to understand for the purpose of a JWT claims registry request. On Sat, Dec 21, 2019 at 4:11 AM Ludwig Seitz wrote: > Hello JWT registry reviewers, > > the IESG-designated experts for the JWT claims registry have asked me to > send a review request to you about the "rs_cnf" claim registered here: > > https://tools.ietf.org/html/draft-ietf-ace-oauth-params-07#section-9.1 > > Thank you in advance for you review comments. > > Regards, > > Ludwig > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000003ea6f9059bcf955c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That=C2=A0 "rs_cnf" claim registration requ= est in 9.1 points to 3.3 which says it has 'the same syntax and semanti= cs as defined in for the "rs_cnf" parameter', which I think i= s in 4.1. And 4.1 says that the "rs_cnf" values 'follow the s= yntax of the "cnf" claim from section 3.1 of [I-D.ietf-ace-cwt-pr= oof-of-possession].' Similar to other comments I've made today, I d= on't follow what that would mean for the value of the claim when it'= ;s a JWT. And that seems like something that's important to understand = for the purpose of a JWT claims registry request.=C2=A0


On Sa= t, Dec 21, 2019 at 4:11 AM Ludwig Seitz <ludwig_seitz@gmx.de> wrote:
Hello JWT registry reviewers,<= br>
the IESG-designated experts for the JWT claims registry have asked me to send a review request to you about the "rs_cnf" claim registered = here:

https://tools.ietf.org/html/dr= aft-ietf-ace-oauth-params-07#section-9.1

Thank you in advance for you review comments.

Regards,

Ludwig

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000003ea6f9059bcf955c-- From nobody Sat Jan 11 07:20:28 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE89012007A; Sat, 11 Jan 2020 07:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHeRjGinCaJp; Sat, 11 Jan 2020 07:20:24 -0800 (PST) Received: from weald2.air.saab.se (weald2.air.saab.se [136.163.212.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED862120045; Sat, 11 Jan 2020 07:20:23 -0800 (PST) Received: from mailhub1.air.saab.se ([136.163.213.4]) by weald2.air.saab.se (8.14.4/8.14.4) with ESMTP id 00BFJawk002276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 11 Jan 2020 16:19:36 +0100 Received: from corpappl16349.corp.saab.se (corpappl16349.corp.saab.se [10.12.12.112]) by mailhub1.air.saab.se (8.13.8/8.13.8) with ESMTP id 00BFJMwo010776 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 11 Jan 2020 16:19:22 +0100 Received: from corpappl16593.corp.saab.se (10.12.12.125) by corpappl16349.corp.saab.se (10.12.12.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Sat, 11 Jan 2020 16:19:22 +0100 Received: from corpappl16593.corp.saab.se ([fe80::b4c9:ca69:a80d:fa3]) by corpappl16593.corp.saab.se ([fe80::b4c9:ca69:a80d:fa3%7]) with mapi id 15.01.1847.003; Sat, 11 Jan 2020 16:19:22 +0100 From: Seitz Ludwig To: Brian Campbell , Ludwig Seitz CC: Roman Danyliw , "oauth-ext-review@ietf.org" , Daniel Migault , Jim Schaad , Benjamin Kaduk , "ace@ietf.org" , "drafts-lastcall@iana.org" Thread-Topic: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params Thread-Index: AQHVudiTycTAqDsElUGbd/7HBhJxNaffobGAgAS/bICAAU4tsA== Date: Sat, 11 Jan 2020 15:19:22 +0000 Message-ID: <2616175d102b4c19a60c6a79d4256b5e@combitech.se> References: <4a5177af-a442-f109-f620-0ae91953eb63@gmx.de> In-Reply-To: Accept-Language: en-SE, sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.13.198] Content-Type: multipart/alternative; boundary="_000_2616175d102b4c19a60c6a79d4256b5ecombitechse_" MIME-Version: 1.0 X-Saab-MailScanner-Information: Please contact the ISP for more information X-Saab-MailScanner-ID: 00BFJMwo010776 X-Saab-MailScanner: Found to be clean X-Saab-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.997, required 5, autolearn=not spam, ALL_TRUSTED -1.00, HTML_MESSAGE 0.00, SURBL_BLOCKED 0.00, URIBL_BLOCKED 0.00) X-Saab-MailScanner-From: ludwig.seitz@combitech.se X-Saab-MailScanner-Watermark: 1579360762.94632@wYrjMdI6UuAFWxdRBg/r/Q X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (weald2.air.saab.se [136.163.212.4]); Sat, 11 Jan 2020 16:19:36 +0100 (CET) Archived-At: Subject: Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2020 15:20:26 -0000 --_000_2616175d102b4c19a60c6a79d4256b5ecombitechse_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQnJpYW4sDQoNClRoYW5rIHlvdSBmb3IgdGhlIHJlLXJldmlldyEgQ29tbWVudHMgaW5s aW5lLg0KSSB3aWxsIGJlIGlzc3VpbmcgYSBkcmFmdCB1cGRhdGUgc29vbi1pc2guDQoNCi9MdWR3 aWcNCg0KRnJvbTogQWNlIDxhY2UtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEJyaWFu IENhbXBiZWxsDQpTZW50OiBkZW4gMTAgamFudWFyaSAyMDIwIDIxOjE2DQpUbzogTHVkd2lnIFNl aXR6IDxsdWR3aWdfc2VpdHpAZ214LmRlPg0KQ2M6IFJvbWFuIERhbnlsaXcgPHJkZEBjZXJ0Lm9y Zz47IG9hdXRoLWV4dC1yZXZpZXdAaWV0Zi5vcmc7IERhbmllbCBNaWdhdWx0IDxkYW5pZWwubWln YXVsdEBlcmljc3Nvbi5jb20+OyBKaW0gU2NoYWFkIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPjsg QmVuamFtaW4gS2FkdWsgPGthZHVrQG1pdC5lZHU+OyBhY2VAaWV0Zi5vcmc7IGRyYWZ0cy1sYXN0 Y2FsbEBpYW5hLm9yZw0KU3ViamVjdDogUmU6IFtBY2VdIFJlcXVlc3RlZCByZXZpZXcgZm9yIElB TkEgcmVnaXN0cmF0aW9uIGluIGRyYWZ0LWlldGYtYWNlLW9hdXRoLXBhcmFtcw0KDQpUaGF0IGNl cnRhaW5seSB0YWtlcyBjYXJlIG9mIHRoZSByZWdpc3RyeSBjb25mbGljdCBwcm9ibGVtLCB0aGFu a3MuDQoNCkknbSBhIGxpdHRsZSBjb25mdXNlZCwgaG93ZXZlciwgYW5kIHVuY2VydGFpbiBpZiB0 aGF0IGNoYW5nZXMgdGhlIHN5bnRheCBpbiBhIHdheSB0aGF0IG1heWJlIHdhc24ndCBpbnRlbmRl ZD8NCg0KW0xTXSBJbmRlZWQuIEdvb2QgY2F0Y2guIEkgYW1lbmRlZCB0aGF0IHRvIHNheSB0aGF0 IGl0IHVzZXMgdGhlIOKAnGNuZuKAnSBwYXJhbWV0ZXIgZm9yIG10bHMsIGJ1dCBmb3IgQ0JPUiBp dCBzaG91bGQgdXNlIHRoZSBzeW50YXggb2YgdGhlIOKAnGNuZuKAnSB2YWx1ZXMgZnJvbSBJLUQu aWV0Zi1hY2UtY3d0LXByb29mLW9mLXBvc3Nlc3Npb24uDQoNCi0wOSBoYWQ6DQogIGNuZg0KICAg ICBPUFRJT05BTC4gIFRoaXMgZmllbGQgY29udGFpbnMgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHBy b29mLW9mLQ0KICAgICBwb3NzZXNzaW9uIGtleSB0aGF0IGJpbmRzIHRoZSBjbGllbnQgdG8gdGhl IGFjY2VzcyB0b2tlbi4gIFZhbHVlcw0KICAgICBvZiB0aGlzIHBhcmFtZXRlciBmb2xsb3cgdGhl IHN5bnRheCBvZiB0aGUgImNuZiIgY2xhaW0gZnJvbQ0KICAgICBzZWN0aW9uIDMuMSBvZiBbSS1E LmlldGYtYWNlLWN3dC1wcm9vZi1vZi1wb3NzZXNzaW9uXS4gIFNlZQ0KICAgICBTZWN0aW9uIDUg Zm9yIGFkZGl0aW9uYWwgZGlzY3Vzc2lvbiBvZiB0aGUgdXNhZ2Ugb2YgdGhpcw0KICAgICBwYXJh bWV0ZXIuDQoNCndoaWxlIC0xMCBoYXM6DQogIEZ1cnRoZXJtb3JlIHRoZSBBUyBjYW4gdXNlIHRo ZSAiY25mIiBwYXJhbWV0ZXIgc3BlY2lmaWVkIGluIHNlY3Rpb24NCiAgOS40IG9mIFtJLUQuaWV0 Zi1vYXV0aC1tdGxzXSBpbiBhbiBpbnRyb3NwZWN0aW9uIHJlc3BvbnNlLiAgRm9yIENCT1ItDQog IGJhc2VkIGludGVyYWN0aW9ucyB0aGUgQVMgTVVTVCB1c2UgdGhlIHBhcmFtZXRlciBtYXBwaW5n IHNwZWNpZmllZCBpbg0KICBGaWd1cmUgNS4NCg0KU28gaW4gLTA5IHRoZSAiY25mIiBJbnRyb3Nw ZWN0aW9uIFJlc3BvbnNlIFBhcmFtZXRlciB3YXMgdGhlIGZvbGxvd2luZyB0aGUgc3ludGF4IG9m IHRoZSAiY25mIiBjbGFpbSBmcm9tIFBvUCBLZXkgU2VtYW50aWNzIGZvciBDV1RzIFtJRC5pZXRm LWFjZS1jd3QtcHJvb2Ytb2YtcG9zc2Vzc2lvbl0gYW5kIGluIC0xMCBpdCdzIGZvbGxvd2luZyB0 aGUgc3ludGF4IG9mIFBvUCBLZXkgU2VtYW50aWNzIGZvciBKV1RzIFtSRkM3ODAwXSB0cmFuc2l0 aXZlbHkgdmlhIFtJLUQuaWV0Zi1vYXV0aC1tdGxzXSByZWZlcmVuY2UuIEkgdGhpbmsgSSB1bmRl cnN0YW5kIHRoYXQgdGhlIHR3byBQb1Aga2V5IHNlbWFudGljcyBkb2N1bWVudHMgYXJlIGNvbmNl cHR1YWxseSB0aGUgc2FtZSBvciBzaW1pbGFyLiBCdXQgSSBkb24ndCBrbm93IHRoYXQgdGhlIHN5 bnRheCBpcyB0aGUgc2FtZT8gRmlndXJlIDU8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtYWNlLW9hdXRoLXBhcmFtcy0xMCNzZWN0aW9uLTY+IGlzIHBvaW50ZWQgdG8gZm9y IG1hcHBpbmcgYmV0d2VlbiBDQk9SIGFuZCBKU09OIGJ1dCBpdCBvbmx5IGhhcyBtYXBwaW5ncyBm b3IgdGhlIG1haW4gdG9wIGxldmVsIHBhcmFtZXRlcnMuIE1heWJlIEkganVzdCBkb24ndCBnZXQg aXQgb3IgYW0gbWlzc2luZyBzb21ldGhpbmcuLi4NCg0KW0xTXSBObyB5b3UgYXJlIG5vdCBtaXNz aW5nIHNvbWV0aGluZywgSSBqdXN0IGdvdCBzbG9wcHkgdHJ5aW5nIHRvIGRvIGEgcXVpY2tmaXgu DQoNCkJhY2tncm91bmQ6IFRoZSByZWFzb24gZm9yIGRlZmluaW5nIGJvdGggSlNPTiBhbmQgQ0JP Ui1iYXNlZCBpbnRlcmFjdGlvbnMgaXMgdGhhdCB5b3UgbWlnaHQgaGF2ZSBhIHBvd2VyZnVsIGNs aWVudCBjb21tdW5pY2F0aW5nIHdpdGggYSBjb25zdHJhaW5lZCBSUy4gVGhlIGNsaWVudCBkb2Vz IHZhbmlsbGEgT0F1dGggaW50ZXJhY3Rpb25zIHdpdGggdGhlIEFTIHZpYSB0aGUgdG9rZW4gZW5k cG9pbnQsIGJ1dCBpcyBzZXJ2ZWQgYSBDV1QgYW5kIGFzc29jaWF0ZWQgQUNFIHBhcmFtZXRlcnMg KGNuZiwgYWNlLXByb2ZpbGUsIOKApikgZm9yIGludGVyYWN0aW9uIHdpdGggdGhlIFJTLg0KVGhl IHBvcC1rZXkgc2hvdWxkIGRlY29kZSB0byB0aGUgc2FtZSBiaW5hcnkgcmVwcmVzZW50YXRpb24g cmVnYXJkbGVzcyBvZiB3aGV0aGVyIGl0IGNhbWUgaW4gYSBKU09OIG9yIENCT1Igd3JhcHBlci4N Cg0KDQoNCg0KDQpPbiBUdWUsIEphbiA3LCAyMDIwIGF0IDEyOjQ2IFBNIEx1ZHdpZyBTZWl0eiA8 bHVkd2lnX3NlaXR6QGdteC5kZTxtYWlsdG86bHVkd2lnX3NlaXR6QGdteC5kZT4+IHdyb3RlOg0K T24gMjAxOS0xMi0yMyAyMjozMiwgQnJpYW4gQ2FtcGJlbGwgd3JvdGU6DQo+IFRoZSBPQXV0aCBU b2tlbiBJbnRyb3NwZWN0aW9uIFJlc3BvbnNlIHJlZ2lzdHJ5DQo+IDxodHRwczovL3d3dy5pYW5h Lm9yZy9hc3NpZ25tZW50cy9vYXV0aC1wYXJhbWV0ZXJzL29hdXRoLXBhcmFtZXRlcnMueGh0bWwj dG9rZW4taW50cm9zcGVjdGlvbi1yZXNwb25zZT4NCj4gYWxyZWFkeSBoYXMgYW4gZW50cnkgZm9y ICJjbmYiLCB3aGljaCBtYWtlcyB0aGUgZmlyc3QgcmVxdWVzdCBpbg0KPiBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hY2Utb2F1dGgtcGFyYW1zLTA3I3NlY3Rpb24tOS40 DQo+IHJhdGhlciBwcm9ibGVtYXRpYy4NCj4NCg0KT0F1dGggYmVhdHMgdXMgb24gdGhlIGZpbmlz aCBsaW5lIGFnYWluIDotKA0KDQpJIGhhdmUgdXBkYXRlZCB0aGUgZHJhZnQgdG8gcmVtb3ZlIHRo ZSByZWdpc3RyYXRpb24gYW5kIHJlZmVyIHRvIHRoZQ0KTVRMUyBkcmFmdC4NCg0KL0x1ZHdpZw0K DQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRl bmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Ns b3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuLiAgSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBm aWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhhbmsgeW91Lg0K --_000_2616175d102b4c19a60c6a79d4256b5ecombitechse_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIg MTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5t c29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFt ZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBj bTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5I ZWxsbyBCcmlhbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRo YW5rIHlvdSBmb3IgdGhlIHJlLXJldmlldyEgQ29tbWVudHMgaW5saW5lLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5JIHdpbGwgYmUgaXNzdWluZyBhIGRyYWZ0IHVwZGF0ZSBzb29uLWlzaC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPi9MdWR3aWc8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQWNlICZs dDthY2UtYm91bmNlc0BpZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+QnJpYW4gQ2Ft cGJlbGw8YnI+DQo8Yj5TZW50OjwvYj4gZGVuIDEwIGphbnVhcmkgMjAyMCAyMToxNjxicj4NCjxi PlRvOjwvYj4gTHVkd2lnIFNlaXR6ICZsdDtsdWR3aWdfc2VpdHpAZ214LmRlJmd0Ozxicj4NCjxi PkNjOjwvYj4gUm9tYW4gRGFueWxpdyAmbHQ7cmRkQGNlcnQub3JnJmd0Ozsgb2F1dGgtZXh0LXJl dmlld0BpZXRmLm9yZzsgRGFuaWVsIE1pZ2F1bHQgJmx0O2RhbmllbC5taWdhdWx0QGVyaWNzc29u LmNvbSZndDs7IEppbSBTY2hhYWQgJmx0O2lldGZAYXVndXN0Y2VsbGFycy5jb20mZ3Q7OyBCZW5q YW1pbiBLYWR1ayAmbHQ7a2FkdWtAbWl0LmVkdSZndDs7IGFjZUBpZXRmLm9yZzsgZHJhZnRzLWxh c3RjYWxsQGlhbmEub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQWNlXSBSZXF1ZXN0ZWQg cmV2aWV3IGZvciBJQU5BIHJlZ2lzdHJhdGlvbiBpbiBkcmFmdC1pZXRmLWFjZS1vYXV0aC1wYXJh bXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBjZXJ0 YWlubHkgdGFrZXMgY2FyZSBvZiB0aGUgcmVnaXN0cnkgY29uZmxpY3QgcHJvYmxlbSwgdGhhbmtz Lg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkknbSBhIGxpdHRsZSBjb25mdXNlZCwgaG93ZXZlciwgYW5kIHVuY2VydGFpbiBpZiB0aGF0IGNo YW5nZXMgdGhlIHN5bnRheCBpbiBhIHdheSB0aGF0IG1heWJlIHdhc24ndCBpbnRlbmRlZD88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W0xTXSBJbmRlZWQu IEdvb2QgY2F0Y2guIEkgYW1lbmRlZCB0aGF0IHRvIHNheSB0aGF0IGl0IHVzZXMgdGhlIOKAnGNu ZuKAnSBwYXJhbWV0ZXIgZm9yIG10bHMsIGJ1dCBmb3IgQ0JPUiBpdCBzaG91bGQgdXNlIHRoZSBz eW50YXggb2YgdGhlIOKAnGNuZuKAnSB2YWx1ZXMgZnJvbSBJLUQuaWV0Zi1hY2UtY3d0LXByb29m LW9mLXBvc3Nlc3Npb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0wOSBoYWQ6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgY25m IDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7T1BUSU9OQUwuJm5ic3A7IFRoaXMgZmllbGQgY29u dGFpbnMgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHByb29mLW9mLSA8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwO3Bvc3Nlc3Npb24ga2V5IHRoYXQgYmluZHMgdGhlIGNsaWVudCB0byB0aGUgYWNjZXNz IHRva2VuLiZuYnNwOyBWYWx1ZXMgPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtvZiB0aGlzIHBh cmFtZXRlciBmb2xsb3cgdGhlIHN5bnRheCBvZiB0aGUgJnF1b3Q7Y25mJnF1b3Q7IGNsYWltIGZy b20gPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtzZWN0aW9uIDMuMSBvZiBbSS1ELmlldGYtYWNl LWN3dC1wcm9vZi1vZi1wb3NzZXNzaW9uXS4mbmJzcDsgU2VlIDxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7U2VjdGlvbiA1IGZvciBhZGRpdGlvbmFsIGRpc2N1c3Npb24gb2YgdGhlIHVzYWdlIG9m IHRoaXMgPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtwYXJhbWV0ZXIuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndoaWxlIC0xMCBoYXM6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsg RnVydGhlcm1vcmUgdGhlIEFTIGNhbiB1c2UgdGhlICZxdW90O2NuZiZxdW90OyBwYXJhbWV0ZXIg c3BlY2lmaWVkIGluIHNlY3Rpb24NCjxicj4NCiZuYnNwOyA5LjQgb2YgW0ktRC5pZXRmLW9hdXRo LW10bHNdIGluIGFuIGludHJvc3BlY3Rpb24gcmVzcG9uc2UuJm5ic3A7IEZvciBDQk9SLSA8YnI+ DQombmJzcDsgYmFzZWQgaW50ZXJhY3Rpb25zIHRoZSBBUyBNVVNUIHVzZSB0aGUgcGFyYW1ldGVy IG1hcHBpbmcgc3BlY2lmaWVkIGluIDxicj4NCiZuYnNwOyBGaWd1cmUgNS4gPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm bmJzcDsgPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5TbyBpbiAtMDkgdGhlICZxdW90O2NuZiZxdW90OyBJbnRyb3NwZWN0aW9uIFJlc3BvbnNlIFBh cmFtZXRlciB3YXMgdGhlIGZvbGxvd2luZyB0aGUgc3ludGF4IG9mIHRoZSAmcXVvdDtjbmYmcXVv dDsgY2xhaW0gZnJvbSBQb1AgS2V5IFNlbWFudGljcyBmb3IgQ1dUcyBbSUQuaWV0Zi1hY2UtY3d0 LXByb29mLW9mLXBvc3Nlc3Npb25dIGFuZCBpbiAtMTAgaXQncyBmb2xsb3dpbmcgdGhlIHN5bnRh eCBvZiBQb1AgS2V5IFNlbWFudGljcyBmb3IgSldUcw0KIFtSRkM3ODAwXSB0cmFuc2l0aXZlbHkg dmlhIFtJLUQuaWV0Zi1vYXV0aC1tdGxzXSByZWZlcmVuY2UuIEkgdGhpbmsgSSB1bmRlcnN0YW5k IHRoYXQgdGhlIHR3byBQb1Aga2V5IHNlbWFudGljcyBkb2N1bWVudHMgYXJlIGNvbmNlcHR1YWxs eSB0aGUgc2FtZSBvciBzaW1pbGFyLiBCdXQgSSBkb24ndCBrbm93IHRoYXQgdGhlIHN5bnRheCBp cyB0aGUgc2FtZT8NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWFjZS1vYXV0aC1wYXJhbXMtMTAjc2VjdGlvbi02IiB0YXJnZXQ9Il9ibGFuayI+DQpGaWd1 cmUgNTwvYT4gaXMgcG9pbnRlZCB0byBmb3IgbWFwcGluZyBiZXR3ZWVuIENCT1IgYW5kIEpTT04g YnV0IGl0IG9ubHkgaGFzIG1hcHBpbmdzIGZvciB0aGUgbWFpbiB0b3AgbGV2ZWwgcGFyYW1ldGVy cy4gTWF5YmUgSSBqdXN0IGRvbid0IGdldCBpdCBvciBhbSBtaXNzaW5nIHNvbWV0aGluZy4uLiAm bmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+W0xTXSBObyB5b3UgYXJlIG5vdCBtaXNz aW5nIHNvbWV0aGluZywgSSBqdXN0IGdvdCBzbG9wcHkgdHJ5aW5nIHRvIGRvIGEgcXVpY2tmaXgu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5CYWNrZ3JvdW5kOiBUaGUgcmVh c29uIGZvciBkZWZpbmluZyBib3RoIEpTT04gYW5kIENCT1ItYmFzZWQgaW50ZXJhY3Rpb25zIGlz IHRoYXQgeW91IG1pZ2h0IGhhdmUgYSBwb3dlcmZ1bCBjbGllbnQgY29tbXVuaWNhdGluZyB3aXRo IGEgY29uc3RyYWluZWQgUlMuIFRoZSBjbGllbnQgZG9lcyB2YW5pbGxhIE9BdXRoIGludGVyYWN0 aW9ucyB3aXRoIHRoZSBBUyB2aWENCiB0aGUgdG9rZW4gZW5kcG9pbnQsIGJ1dCBpcyBzZXJ2ZWQg YSBDV1QgYW5kIGFzc29jaWF0ZWQgQUNFIHBhcmFtZXRlcnMgKGNuZiwgYWNlLXByb2ZpbGUsIOKA pikgZm9yIGludGVyYWN0aW9uIHdpdGggdGhlIFJTLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoZSBwb3At a2V5IHNob3VsZCBkZWNvZGUgdG8gdGhlIHNhbWUgYmluYXJ5IHJlcHJlc2VudGF0aW9uIHJlZ2Fy ZGxlc3Mgb2Ygd2hldGhlciBpdCBjYW1lIGluIGEgSlNPTiBvciBDQk9SIHdyYXBwZXIuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBUdWUsIEphbiA3LCAyMDIwIGF0IDEyOjQ2IFBNIEx1ZHdpZyBTZWl0eiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmx1ZHdpZ19zZWl0ekBnbXguZGUiIHRhcmdldD0iX2JsYW5rIj5sdWR3 aWdfc2VpdHpAZ214LmRlPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPk9uIDIwMTktMTItMjMgMjI6MzIsIEJyaWFuIENhbXBiZWxsIHdyb3RlOjxicj4NCiZndDsg VGhlIE9BdXRoIFRva2VuIEludHJvc3BlY3Rpb24gUmVzcG9uc2UgcmVnaXN0cnk8YnI+DQomZ3Q7 ICZsdDs8YSBocmVmPSJodHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9vYXV0aC1wYXJh bWV0ZXJzL29hdXRoLXBhcmFtZXRlcnMueGh0bWwjdG9rZW4taW50cm9zcGVjdGlvbi1yZXNwb25z ZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL29hdXRo LXBhcmFtZXRlcnMvb2F1dGgtcGFyYW1ldGVycy54aHRtbCN0b2tlbi1pbnRyb3NwZWN0aW9uLXJl c3BvbnNlPC9hPiZndDs8YnI+DQomZ3Q7IGFscmVhZHkgaGFzIGFuIGVudHJ5IGZvciAmcXVvdDtj bmYmcXVvdDssIHdoaWNoIG1ha2VzIHRoZSBmaXJzdCByZXF1ZXN0IGluPGJyPg0KJmd0OyA8YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hY2Utb2F1dGgtcGFy YW1zLTA3I3NlY3Rpb24tOS40IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1hY2Utb2F1dGgtcGFyYW1zLTA3I3NlY3Rpb24tOS40PC9hPjxi cj4NCiZndDsgcmF0aGVyIHByb2JsZW1hdGljLjxicj4NCiZndDs8YnI+DQo8YnI+DQpPQXV0aCBi ZWF0cyB1cyBvbiB0aGUgZmluaXNoIGxpbmUgYWdhaW4gOi0oPGJyPg0KPGJyPg0KSSBoYXZlIHVw ZGF0ZWQgdGhlIGRyYWZ0IHRvIHJlbW92ZSB0aGUgcmVnaXN0cmF0aW9uIGFuZCByZWZlciB0byB0 aGU8YnI+DQpNVExTIGRyYWZ0Ljxicj4NCjxicj4NCi9MdWR3aWc8bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojNTU1NTU1O2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7 cGFkZGluZzowY20iPkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ug b2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4NCiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1 dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLi4mbmJz cDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhl IG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRlci4gVGhh bmsgeW91Ljwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_2616175d102b4c19a60c6a79d4256b5ecombitechse_-- From nobody Sat Jan 11 07:36:47 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 980DC120045; Sat, 11 Jan 2020 07:36:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <157875700543.26032.4331059386050382232@ietfa.amsl.com> Date: Sat, 11 Jan 2020 07:36:45 -0800 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oauth-params-11.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2020 15:36:46 -0000 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 : Additional OAuth Parameters for Authorization in Constrained Environments (ACE) Author : Ludwig Seitz Filename : draft-ietf-ace-oauth-params-11.txt Pages : 13 Date : 2020-01-11 Abstract: This specification defines new parameters for the OAuth 2.0 token and introspection endpoints when used with the framework for authentication and authorization for constrained environments (ACE). These are used to express the proof-of-possession key the client wishes to use, the proof-of-possession key that the Authorization Server has selected, and the key the Resource Server should use to authenticate to the client. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-params/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oauth-params-11 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-params-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-params-11 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/ From nobody Sat Jan 11 07:38:39 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEAE9120091 for ; Sat, 11 Jan 2020 07:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZXod1dkYo47 for ; Sat, 11 Jan 2020 07:38:34 -0800 (PST) Received: from weald2.air.saab.se (weald2.air.saab.se [136.163.212.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 632EF120045 for ; Sat, 11 Jan 2020 07:38:34 -0800 (PST) Received: from mailhub1.air.saab.se ([136.163.213.4]) by weald2.air.saab.se (8.14.4/8.14.4) with ESMTP id 00BFcWYs003795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 11 Jan 2020 16:38:32 +0100 Received: from corpappl16590.corp.saab.se (corpappl16590.corp.saab.se [10.12.12.96]) by mailhub1.air.saab.se (8.13.8/8.13.8) with ESMTP id 00BFcJ6a025398 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sat, 11 Jan 2020 16:38:19 +0100 Received: from corpappl16593.corp.saab.se (10.12.12.125) by corpappl16590.corp.saab.se (10.12.12.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Sat, 11 Jan 2020 16:38:19 +0100 Received: from corpappl16593.corp.saab.se ([fe80::b4c9:ca69:a80d:fa3]) by corpappl16593.corp.saab.se ([fe80::b4c9:ca69:a80d:fa3%7]) with mapi id 15.01.1847.003; Sat, 11 Jan 2020 16:38:19 +0100 From: Seitz Ludwig To: "ace@ietf.org" Thread-Topic: New Version Notification for draft-ietf-ace-oauth-params-11.txt Thread-Index: AQHVyJT6kfb2OfIDHEy72uqwDnLKKaflmOMQ Date: Sat, 11 Jan 2020 15:38:19 +0000 Message-ID: <46a11f19fe0344b6902af4db456a5289@combitech.se> References: <157875700579.26032.12611345185829970252.idtracker@ietfa.amsl.com> In-Reply-To: <157875700579.26032.12611345185829970252.idtracker@ietfa.amsl.com> Accept-Language: en-SE, sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.13.198] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Saab-MailScanner-Information: Please contact the ISP for more information X-Saab-MailScanner-ID: 00BFcJ6a025398 X-Saab-MailScanner: Found to be clean X-Saab-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.498, required 5, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -0.50, SURBL_BLOCKED 0.00, URIBL_BLOCKED 0.00) X-Saab-MailScanner-From: ludwig.seitz@combitech.se X-Saab-MailScanner-Watermark: 1579361899.90415@OH3zehfnJNIa1AQt27aT9Q X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (weald2.air.saab.se [136.163.212.4]); Sat, 11 Jan 2020 16:38:32 +0100 (CET) Archived-At: Subject: [Ace] FW: New Version Notification for draft-ietf-ace-oauth-params-11.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2020 15:38:37 -0000 SGVsbG8gQUNFIHRoaXMgZml4ZXMgdGhlIHJldmlldyBjb21tZW50cyBieSBCcmlhbiBDYW1wYmVs bCwgdGhlIGRlc2lnbmF0ZWQgZXhwZXJ0IGZyb20gSUFOQSBmb3IgdGhlIE9BdXRoIGFuZCBKV1Qg cmVnaXN0cmllcy4NCg0KUmVnYXJkcywNCg0KTHVkd2lnDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgPGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZz4gDQpTZW50OiBkZW4gMTEgamFudWFyaSAyMDIwIDE2OjM3DQpUbzogU2VpdHogTHVk d2lnIDxsdWR3aWcuc2VpdHpAY29tYml0ZWNoLnNlPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLWFjZS1vYXV0aC1wYXJhbXMtMTEudHh0DQoNCg0KQSBu ZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtYWNlLW9hdXRoLXBhcmFtcy0xMS50eHQNCmhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTHVkd2lnIFNlaXR6IGFuZCBwb3N0ZWQg dG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWlldGYtYWNlLW9hdXRoLXBh cmFtcw0KUmV2aXNpb246CTExDQpUaXRsZToJCUFkZGl0aW9uYWwgT0F1dGggUGFyYW1ldGVycyBm b3IgQXV0aG9yaXphdGlvbiBpbiBDb25zdHJhaW5lZCBFbnZpcm9ubWVudHMgKEFDRSkNCkRvY3Vt ZW50IGRhdGU6CTIwMjAtMDEtMTENCkdyb3VwOgkJYWNlDQpQYWdlczoJCTEzDQpVUkw6ICAgICAg ICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtYWNl LW9hdXRoLXBhcmFtcy0xMS50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWFjZS1vYXV0aC1wYXJhbXMvDQpIdG1saXplZDogICAg ICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYWNlLW9hdXRoLXBhcmFt cy0xMQ0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0 bWwvZHJhZnQtaWV0Zi1hY2Utb2F1dGgtcGFyYW1zDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtYWNlLW9hdXRoLXBhcmFtcy0xMQ0K DQpBYnN0cmFjdDoNCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIG5ldyBwYXJhbWV0ZXJz IGZvciB0aGUgT0F1dGggMi4wIHRva2VuIGFuZA0KICAgaW50cm9zcGVjdGlvbiBlbmRwb2ludHMg d2hlbiB1c2VkIHdpdGggdGhlIGZyYW1ld29yayBmb3INCiAgIGF1dGhlbnRpY2F0aW9uIGFuZCBh dXRob3JpemF0aW9uIGZvciBjb25zdHJhaW5lZCBlbnZpcm9ubWVudHMgKEFDRSkuDQogICBUaGVz ZSBhcmUgdXNlZCB0byBleHByZXNzIHRoZSBwcm9vZi1vZi1wb3NzZXNzaW9uIGtleSB0aGUgY2xp ZW50DQogICB3aXNoZXMgdG8gdXNlLCB0aGUgcHJvb2Ytb2YtcG9zc2Vzc2lvbiBrZXkgdGhhdCB0 aGUgQXV0aG9yaXphdGlvbg0KICAgU2VydmVyIGhhcyBzZWxlY3RlZCwgYW5kIHRoZSBrZXkgdGhl IFJlc291cmNlIFNlcnZlciBzaG91bGQgdXNlIHRvDQogICBhdXRoZW50aWNhdGUgdG8gdGhlIGNs aWVudC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQg aXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Np b24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0 b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Sat Jan 11 08:16:28 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31024120059; Sat, 11 Jan 2020 08:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flDneQU2gkuh; Sat, 11 Jan 2020 08:16:22 -0800 (PST) Received: from weald.air.saab.se (weald.air.saab.se [136.163.212.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31F81120026; Sat, 11 Jan 2020 08:16:21 -0800 (PST) Received: from mailhub2.air.saab.se ([136.163.213.5]) by weald.air.saab.se (8.14.4/8.14.4) with ESMTP id 00BGFfTn032334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 11 Jan 2020 17:15:41 +0100 Received: from corpappl16589.corp.saab.se (corpappl16589.corp.saab.se [10.12.12.95]) by mailhub2.air.saab.se (8.13.8/8.13.8) with ESMTP id 00BGFRnr021392 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 11 Jan 2020 17:15:27 +0100 Received: from corpappl16593.corp.saab.se (10.12.12.125) by corpappl16589.corp.saab.se (10.12.12.95) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Sat, 11 Jan 2020 17:15:26 +0100 Received: from corpappl16593.corp.saab.se ([fe80::b4c9:ca69:a80d:fa3]) by corpappl16593.corp.saab.se ([fe80::b4c9:ca69:a80d:fa3%7]) with mapi id 15.01.1847.003; Sat, 11 Jan 2020 17:15:26 +0100 From: Seitz Ludwig To: Brian Campbell , Ludwig Seitz CC: Roman Danyliw , "jwt-reg-review@ietf.org" , Jim Schaad , The IESG , "ace@ietf.org" , "drafts-lastcall@iana.org" , Benjamin Kaduk Thread-Topic: [Ace] [Jwt-reg-review] Requested review for IANA registration in draft-ietf-ace-oauth-authz Thread-Index: AQHVx/itFokTZysKCk+AI7dgOCua26flotpw Date: Sat, 11 Jan 2020 16:15:26 +0000 Message-ID: <14a3c79d23e94d938be4a173a6c8256d@combitech.se> References: <9c32d171-9a4a-ba71-c989-92a177d9e989@gmx.de> In-Reply-To: Accept-Language: en-SE, sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.13.198] Content-Type: multipart/alternative; boundary="_000_14a3c79d23e94d938be4a173a6c8256dcombitechse_" MIME-Version: 1.0 X-Saab-MailScanner-Information: Please contact the ISP for more information X-Saab-MailScanner-ID: 00BGFRnr021392 X-Saab-MailScanner: Found to be clean X-Saab-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.92, required 5, autolearn=not spam, ALL_TRUSTED -1.00, HTML_MESSAGE 0.00, SURBL_BLOCKED 0.00, TW_JW 0.08, URIBL_BLOCKED 0.00) X-Saab-MailScanner-From: ludwig.seitz@combitech.se X-Saab-MailScanner-Watermark: 1579364128.27414@5nz+9RlS4hF1YOksgLLgKg X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (weald.air.saab.se [136.163.212.3]); Sat, 11 Jan 2020 17:15:42 +0100 (CET) Archived-At: Subject: Re: [Ace] [Jwt-reg-review] Requested review for IANA registration in draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2020 16:16:24 -0000 --_000_14a3c79d23e94d938be4a173a6c8256dcombitechse_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQnJpYW4sDQoNClRoYW5rIHlvdSBmb3IgdGhpcyByZXZpZXchDQpJIGhhdmUgYWRkZWQg dGV4dCB0byBjbGFyaWZ5IHRoZSBmb3JtYXR0aW5nIG9mIHRoZXNlIHBhcmFtZXRlcnMgYW5kIGNs YWltcyB3aGVuIHVzZWQgaW4gSlNPTi1iYXNlZCBpbnRlcmFjdGlvbnMuDQpNb3JlIGNvbW1lbnRz IGlubGluZS4NCg0KUmVnYXJkcywNCkx1ZHdpZw0KDQpGcm9tOiBBY2UgPGFjZS1ib3VuY2VzQGll dGYub3JnPiBPbiBCZWhhbGYgT2YgQnJpYW4gQ2FtcGJlbGwNClNlbnQ6IGRlbiAxMCBqYW51YXJp IDIwMjAgMjE6NTcNClRvOiBMdWR3aWcgU2VpdHogPGx1ZHdpZ19zZWl0ekBnbXguZGU+DQpDYzog Um9tYW4gRGFueWxpdyA8cmRkQGNlcnQub3JnPjsgand0LXJlZy1yZXZpZXdAaWV0Zi5vcmc7IEpp bSBTY2hhYWQgPGlldGZAYXVndXN0Y2VsbGFycy5jb20+OyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9y Zz47IGFjZUBpZXRmLm9yZzsgZHJhZnRzLWxhc3RjYWxsQGlhbmEub3JnOyBCZW5qYW1pbiBLYWR1 ayA8a2FkdWtAbWl0LmVkdT4NClN1YmplY3Q6IFJlOiBbQWNlXSBbSnd0LXJlZy1yZXZpZXddIFJl cXVlc3RlZCByZXZpZXcgZm9yIElBTkEgcmVnaXN0cmF0aW9uIGluIGRyYWZ0LWlldGYtYWNlLW9h dXRoLWF1dGh6DQoNCkknbSByZWFsbHkgc3RydWdnbGluZyB3aXRoIHVuZGVyc3RhbmRpbmcgd2hh dCB0aGUgdmFsdWUgb2YgYW4gImFjZV9wcm9maWxlIiBjbGFpbSBhY3R1YWxseSB3b3VsZCBiZSBp biBhIEpXVC4gQSBKU09OIHN0cmluZyB0aGF0J3MgdGhlIHByb2ZpbGUgbmFtZSAodGhvdWdoIDUu Ni40LjMgbWF5YmUgcHJvaGliaXRzDQp0aGF0KT8gIEEgSlNPTiBudW1iZXIgdGhhdCdzIGFuIGlu dGVnZXIgbWF0Y2hpbmcgdGhlIENCT1IgVmFsdWU/IFNvbWV0aGluZyBlbHNlPw0KDQpbTFNdIEZv ciBKU09OIHRoZSBzdHJpbmcgcmVwcmVzZW50YXRpb24gaXMgb2ssIEkgcmV3b3JkZWQgNS42LjQu MyB0byBjbGFyaWZ5IHRoaXMuDQoNCklzIHRoZSB2YWx1ZSBvZiAiZXhpIiBpbiBhIEpXVCBhIEpT T04gbnVtYmVyPyBTZWVtcyBsaWtlbHkgYnV0IGl0J3Mgc29tZXRoaW5nIHRoYXQgc2hvdWxkIHBy b2JhYmx5IGJlIG1hZGUgZXhwbGljaXQuDQoNCltMU10gTm93IGV4cGxpY2l0DQoNCkFsc28gZm9y ICJleGkiLCB0aGUgcmVxdWlyZW1lbnQgaW4gNS44LjMuIHRvICJrZWVwIHRyYWNrIG9mIHRoZSBp ZGVudGlmaWVycyBvZiB0b2tlbnMgY29udGFpbmluZyB0aGUgImV4aSIgY2xhaW0gdGhhdCBoYXZl IGV4cGlyZWQgKGluIG9yZGVyIHRvIGF2b2lkIGFjY2VwdGluZyB0aGVtIGFnYWluKSIgc2VlbXMg cHJvYmxlbWF0aWMgaW4gdGhhdCBpdCBzb3VuZHMgbGlrZSBpdCdzIG1hbmRhdGluZyBhbiB1bmJv dW5kZWQgZ3Jvd3RoIG9mIG1lbW9yeSB1c2UuDQoNClNlY3Rpb24gNi42LiBwcm9wb3NlcyBhIG1p dGlnYXRpb24gZm9yIHRoZSB1bmJvdW5kZWQgZ3Jvd3RoIG9mIG1lbW9yeSB1c2UgcHJvYmxlbS4g RG9lcyB0aGF0IHJlc29sdmUgeW91ciByZXNlcnZhdGlvbnM/DQoNClRoZSBkcmFmdCBzYXlzIHRo YXQgdGhlICJjbm9uY2UiIGNsYWltICh2YWx1ZSkgdXNlcyBiaW5hcnkgZW5jb2RpbmcuIFdoYXQg ZG9lcyB0aGF0IG1lYW4gZm9yIEpTT04gYmFzZWQgSldUPw0KDQpbTFNdIE5vdyBCYXNlNjQgZW5j b2RlZCBiaW5hcnkgZm9yIEpTT04uDQoNCk9uIFNhdCwgRGVjIDIxLCAyMDE5IGF0IDQ6MzUgQU0g THVkd2lnIFNlaXR6IDxsdWR3aWdfc2VpdHpAZ214LmRlPG1haWx0bzpsdWR3aWdfc2VpdHpAZ214 LmRlPj4gd3JvdGU6DQpIZWxsbyBKV1QgcmVnaXN0cnkgcmV2aWV3ZXJzLA0KDQp0aGUgSUVTRy1k ZXNpZ25hdGVkIGV4cGVydHMgZm9yIHRoZSBKV1QgY2xhaW1zIHJlZ2lzdHJ5IGhhdmUgYXNrZWQg bWUgdG8NCnNlbmQgYSByZXZpZXcgcmVxdWVzdCB0byB5b3UgYWJvdXQgdGhlIGNsYWltcyByZWdp c3RlcmVkIGhlcmU6DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFj ZS1vYXV0aC1hdXRoei0yOSNzZWN0aW9uLTguMTINCg0KVGhhbmsgeW91IGluIGFkdmFuY2UgZm9y IHlvdSByZXZpZXcgY29tbWVudHMuDQoNClJlZ2FyZHMsDQoNCkx1ZHdpZw0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSnd0LXJlZy1yZXZpZXcgbWFp bGluZyBsaXN0DQpKd3QtcmVnLXJldmlld0BpZXRmLm9yZzxtYWlsdG86Snd0LXJlZy1yZXZpZXdA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2p3dC1yZWct cmV2aWV3DQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4g Y29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2Yg dGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24g b3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4uICBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBh bmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQo= --_000_14a3c79d23e94d938be4a173a6c8256dcombitechse_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIg MTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5t c29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFt ZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBj bTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5I ZWxsbyBCcmlhbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRo YW5rIHlvdSBmb3IgdGhpcyByZXZpZXchPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgaGF2ZSBhZGRlZCB0 ZXh0IHRvIGNsYXJpZnkgdGhlIGZvcm1hdHRpbmcgb2YgdGhlc2UgcGFyYW1ldGVycyBhbmQgY2xh aW1zIHdoZW4gdXNlZCBpbiBKU09OLWJhc2VkIGludGVyYWN0aW9ucy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+TW9yZSBjb21tZW50cyBpbmxpbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5SZWdhcmRzLDxicj4NCkx1ZHdpZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBBY2UgJmx0O2FjZS1ib3Vu Y2VzQGlldGYub3JnJmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5CcmlhbiBDYW1wYmVsbDxicj4N CjxiPlNlbnQ6PC9iPiBkZW4gMTAgamFudWFyaSAyMDIwIDIxOjU3PGJyPg0KPGI+VG86PC9iPiBM dWR3aWcgU2VpdHogJmx0O2x1ZHdpZ19zZWl0ekBnbXguZGUmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBS b21hbiBEYW55bGl3ICZsdDtyZGRAY2VydC5vcmcmZ3Q7OyBqd3QtcmVnLXJldmlld0BpZXRmLm9y ZzsgSmltIFNjaGFhZCAmbHQ7aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbSZndDs7IFRoZSBJRVNHICZs dDtpZXNnQGlldGYub3JnJmd0OzsgYWNlQGlldGYub3JnOyBkcmFmdHMtbGFzdGNhbGxAaWFuYS5v cmc7IEJlbmphbWluIEthZHVrICZsdDtrYWR1a0BtaXQuZWR1Jmd0Ozxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW0FjZV0gW0p3dC1yZWctcmV2aWV3XSBSZXF1ZXN0ZWQgcmV2aWV3IGZvciBJQU5B IHJlZ2lzdHJhdGlvbiBpbiBkcmFmdC1pZXRmLWFjZS1vYXV0aC1hdXRoejxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gcmVhbGx5IHN0cnVnZ2xpbmcgd2l0 aCB1bmRlcnN0YW5kaW5nIHdoYXQgdGhlIHZhbHVlIG9mIGFuICZxdW90O2FjZV9wcm9maWxlJnF1 b3Q7IGNsYWltIGFjdHVhbGx5IHdvdWxkIGJlIGluIGEgSldULiBBIEpTT04gc3RyaW5nIHRoYXQn cyB0aGUgcHJvZmlsZSBuYW1lICh0aG91Z2ggNS42LjQuMyBtYXliZSBwcm9oaWJpdHMNCjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj50aGF0KT8mbmJzcDsgQSBKU09OIG51bWJlciB0aGF0J3MgYW4gaW50ZWdlciBt YXRjaGluZyB0aGUgQ0JPUiBWYWx1ZT8gU29tZXRoaW5nIGVsc2U/Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltMU10gRm9yIEpTT04gdGhlIHN0cmluZyByZXByZXNl bnRhdGlvbiBpcyBvaywgSSByZXdvcmRlZCA1LjYuNC4zIHRvIGNsYXJpZnkgdGhpcy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklz IHRoZSB2YWx1ZSBvZiAmcXVvdDtleGkmcXVvdDsgaW4gYSBKV1QgYSBKU09OIG51bWJlcj8gU2Vl bXMgbGlrZWx5IGJ1dCBpdCdzIHNvbWV0aGluZyB0aGF0IHNob3VsZCBwcm9iYWJseSBiZSBtYWRl IGV4cGxpY2l0Lg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltMU10gTm93 IGV4cGxpY2l0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5BbHNvIGZvciAmcXVvdDtleGkmcXVvdDssIHRoZSByZXF1aXJlbWVudCBp biA1LjguMy4gdG8gJnF1b3Q7a2VlcCB0cmFjayBvZiB0aGUgaWRlbnRpZmllcnMgb2YgdG9rZW5z IGNvbnRhaW5pbmcgdGhlICZxdW90O2V4aSZxdW90OyBjbGFpbSB0aGF0IGhhdmUgZXhwaXJlZCAo aW4gb3JkZXIgdG8gYXZvaWQgYWNjZXB0aW5nIHRoZW0gYWdhaW4pJnF1b3Q7IHNlZW1zIHByb2Js ZW1hdGljIGluIHRoYXQgaXQgc291bmRzIGxpa2UgaXQncyBtYW5kYXRpbmcgYW4gdW5ib3VuZGVk DQogZ3Jvd3RoIG9mIG1lbW9yeSB1c2UuIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5TZWN0aW9uIDYuNi4gcHJvcG9zZXMgYSBtaXRpZ2F0aW9uIGZvciB0 aGUgdW5ib3VuZGVkIGdyb3d0aCBvZiBtZW1vcnkgdXNlIHByb2JsZW0uIERvZXMgdGhhdCByZXNv bHZlIHlvdXIgcmVzZXJ2YXRpb25zPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZHJh ZnQgc2F5cyB0aGF0IHRoZSAmcXVvdDtjbm9uY2UmcXVvdDsgY2xhaW0gKHZhbHVlKSB1c2VzIGJp bmFyeSBlbmNvZGluZy4gV2hhdCBkb2VzIHRoYXQgbWVhbiBmb3IgSlNPTiBiYXNlZCBKV1Q/DQo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltMU10gTm93 IEJhc2U2NCBlbmNvZGVkIGJpbmFyeSBmb3IgSlNPTi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBTYXQsIERlYyAyMSwgMjAxOSBhdCA0OjM1IEFNIEx1ZHdpZyBTZWl0eiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmx1ZHdpZ19zZWl0ekBnbXguZGUiPmx1ZHdpZ19zZWl0ekBnbXguZGU8L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBj bSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkhlbGxvIEpXVCByZWdpc3RyeSByZXZpZXdlcnMsPGJyPg0KPGJyPg0KdGhlIElF U0ctZGVzaWduYXRlZCBleHBlcnRzIGZvciB0aGUgSldUIGNsYWltcyByZWdpc3RyeSBoYXZlIGFz a2VkIG1lIHRvPGJyPg0Kc2VuZCBhIHJldmlldyByZXF1ZXN0IHRvIHlvdSBhYm91dCB0aGUgY2xh aW1zIHJlZ2lzdGVyZWQgaGVyZTo8YnI+DQo8YnI+DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hY2Utb2F1dGgtYXV0aHotMjkjc2VjdGlvbi04LjEyIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYWNl LW9hdXRoLWF1dGh6LTI5I3NlY3Rpb24tOC4xMjwvYT48YnI+DQo8YnI+DQpUaGFuayB5b3UgaW4g YWR2YW5jZSBmb3IgeW91IHJldmlldyBjb21tZW50cy48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4N Cjxicj4NCkx1ZHdpZzxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KSnd0LXJlZy1yZXZpZXcgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOkp3dC1yZWctcmV2aWV3QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Snd0 LXJlZy1yZXZpZXdAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9qd3QtcmVnLXJldmlldyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vand0LXJlZy1yZXZpZXc8L2E+PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzU1NTU1NTtib3JkZXI6bm9uZSB3aW5k b3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIj5DT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVt YWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3Ig dGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuDQogQW55IHJldmlldywg dXNlLCBkaXN0cmlidXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJv aGliaXRlZC4uJm5ic3A7IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBh bmQgZGVsZXRlIHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIg Y29tcHV0ZXIuIFRoYW5rIHlvdS48L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_14a3c79d23e94d938be4a173a6c8256dcombitechse_-- From nobody Sat Jan 11 08:20:28 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA651120026; Sat, 11 Jan 2020 08:20:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <157875961480.26110.3159773667388425299@ietfa.amsl.com> Date: Sat, 11 Jan 2020 08:20:14 -0800 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oauth-authz-30.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2020 16:20:15 -0000 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 : Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) Authors : Ludwig Seitz Goeran Selander Erik Wahlstroem Samuel Erdtman Hannes Tschofenig Filename : draft-ietf-ace-oauth-authz-30.txt Pages : 87 Date : 2020-01-11 Abstract: This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE- OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-30 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-30 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-30 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/ From nobody Sat Jan 11 08:22:03 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49109120048 for ; Sat, 11 Jan 2020 08:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4sSxr7f1X00 for ; Sat, 11 Jan 2020 08:21:58 -0800 (PST) Received: from weald.air.saab.se (weald.air.saab.se [136.163.212.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA368120026 for ; Sat, 11 Jan 2020 08:21:57 -0800 (PST) Received: from mailhub2.air.saab.se ([136.163.213.5]) by weald.air.saab.se (8.14.4/8.14.4) with ESMTP id 00BGLtrh000598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 11 Jan 2020 17:21:55 +0100 Received: from corpappl16350.corp.saab.se (corpappl16350.corp.saab.se [10.12.12.113]) by mailhub2.air.saab.se (8.13.8/8.13.8) with ESMTP id 00BGLfvf026272 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sat, 11 Jan 2020 17:21:41 +0100 Received: from corpappl16593.corp.saab.se (10.12.12.125) by corpappl16350.corp.saab.se (10.12.12.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Sat, 11 Jan 2020 17:21:41 +0100 Received: from corpappl16593.corp.saab.se ([fe80::b4c9:ca69:a80d:fa3]) by corpappl16593.corp.saab.se ([fe80::b4c9:ca69:a80d:fa3%7]) with mapi id 15.01.1847.003; Sat, 11 Jan 2020 17:21:40 +0100 From: Seitz Ludwig To: "ace@ietf.org" Thread-Topic: New Version Notification for draft-ietf-ace-oauth-authz-30.txt Thread-Index: AQHVyJsOX6f0LhLo2E2fL4yDJV8EUqflpQJQ Date: Sat, 11 Jan 2020 16:21:40 +0000 Message-ID: <84f0350b2b9a46398f024e39be26b15d@combitech.se> References: <157875961509.26110.8676746930170881208.idtracker@ietfa.amsl.com> In-Reply-To: <157875961509.26110.8676746930170881208.idtracker@ietfa.amsl.com> Accept-Language: en-SE, sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.13.198] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Saab-MailScanner-Information: Please contact the ISP for more information X-Saab-MailScanner-ID: 00BGLfvf026272 X-Saab-MailScanner: Found to be clean X-Saab-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.498, required 5, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -0.50, SURBL_BLOCKED 0.00, URIBL_BLOCKED 0.00) X-Saab-MailScanner-From: ludwig.seitz@combitech.se X-Saab-MailScanner-Watermark: 1579364501.36864@ar8pq+N5ZZAK9aLKHTtT+w X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (weald.air.saab.se [136.163.212.3]); Sat, 11 Jan 2020 17:21:55 +0100 (CET) Archived-At: Subject: [Ace] FW: New Version Notification for draft-ietf-ace-oauth-authz-30.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2020 16:22:01 -0000 SGVsbG8gQUNFLA0KDQpUaGlzIHVwZGF0ZSBmaXhlcyB0aGUgcmV2aWV3IGNvbW1lbnRzIGZyb20g dGhlIElBTkEgZGVzaWduYXRlZCBleHBlcnQgQnJpYW4gQ2FtcGJlbGwgZm9yIHRoZQ0KT0F1dGgg cmVnaXN0cmllcy4NCg0KL0x1ZHdpZw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IA0K U2VudDogZGVuIDExIGphbnVhcmkgMjAyMCAxNzoyMA0KVG86IEhhbm5lcyBUc2Nob2ZlbmlnIDxo YW5uZXMudHNjaG9mZW5pZ0Bhcm0uY29tPjsgR29lcmFuIFNlbGFuZGVyIDxnb3Jhbi5zZWxhbmRl ckBlcmljc3Nvbi5jb20+OyBTYW11ZWwgRXJkdG1hbiA8ZXJkdG1hbkBzcG90aWZ5LmNvbT47IFNl aXR6IEx1ZHdpZyA8bHVkd2lnLnNlaXR6QGNvbWJpdGVjaC5zZT47IEVyaWsgV2FobHN0cm9lbSA8 ZXJpa0B3YWhsc3Ryb21zdGVrbmlza2Euc2U+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LWlldGYtYWNlLW9hdXRoLWF1dGh6LTMwLnR4dA0KDQoNCkEgbmV3IHZl cnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLWFjZS1vYXV0aC1hdXRoei0zMC50eHQgaGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBMdWR3aWcgU2VpdHogYW5kIHBvc3RlZCB0byB0aGUg SUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtaWV0Zi1hY2Utb2F1dGgtYXV0aHoNClJl dmlzaW9uOgkzMA0KVGl0bGU6CQlBdXRoZW50aWNhdGlvbiBhbmQgQXV0aG9yaXphdGlvbiBmb3Ig Q29uc3RyYWluZWQgRW52aXJvbm1lbnRzIChBQ0UpIHVzaW5nIHRoZSBPQXV0aCAyLjAgRnJhbWV3 b3JrIChBQ0UtT0F1dGgpDQpEb2N1bWVudCBkYXRlOgkyMDIwLTAxLTExDQpHcm91cDoJCWFjZQ0K UGFnZXM6CQk4Nw0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1pZXRmLWFjZS1vYXV0aC1hdXRoei0zMC50eHQNClN0YXR1czogICAgICAg ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWFjZS1vYXV0aC1h dXRoei8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1hY2Utb2F1dGgtYXV0aHotMzANCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtYWNlLW9hdXRoLWF1dGh6DQpEaWZmOiAg ICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtYWNl LW9hdXRoLWF1dGh6LTMwDQoNCkFic3RyYWN0Og0KICAgVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmlu ZXMgYSBmcmFtZXdvcmsgZm9yIGF1dGhlbnRpY2F0aW9uIGFuZA0KICAgYXV0aG9yaXphdGlvbiBp biBJbnRlcm5ldCBvZiBUaGluZ3MgKElvVCkgZW52aXJvbm1lbnRzIGNhbGxlZCBBQ0UtDQogICBP QXV0aC4gIFRoZSBmcmFtZXdvcmsgaXMgYmFzZWQgb24gYSBzZXQgb2YgYnVpbGRpbmcgYmxvY2tz IGluY2x1ZGluZw0KICAgT0F1dGggMi4wIGFuZCB0aGUgQ29uc3RyYWluZWQgQXBwbGljYXRpb24g UHJvdG9jb2wgKENvQVApLCB0aHVzDQogICB0cmFuc2Zvcm1pbmcgYSB3ZWxsLWtub3duIGFuZCB3 aWRlbHkgdXNlZCBhdXRob3JpemF0aW9uIHNvbHV0aW9uIGludG8NCiAgIGEgZm9ybSBzdWl0YWJs ZSBmb3IgSW9UIGRldmljZXMuICBFeGlzdGluZyBzcGVjaWZpY2F0aW9ucyBhcmUgdXNlZA0KICAg d2hlcmUgcG9zc2libGUsIGJ1dCBleHRlbnNpb25zIGFyZSBhZGRlZCBhbmQgcHJvZmlsZXMgYXJl IGRlZmluZWQgdG8NCiAgIGJldHRlciBzZXJ2ZSB0aGUgSW9UIHVzZSBjYXNlcy4NCg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4N Cg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Sat Jan 11 12:37:20 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659F7120019; Sat, 11 Jan 2020 12:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4v0FY7ou2L0; Sat, 11 Jan 2020 12:37:10 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79A9312004C; Sat, 11 Jan 2020 12:37:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B662ABE24; Sat, 11 Jan 2020 20:37:06 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCcmOzuHa_FA; Sat, 11 Jan 2020 20:37:04 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3AF4BBE20; Sat, 11 Jan 2020 20:37:03 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1578775023; bh=+pfd4Owh8V6bNthiDDhbA2SmmA+wQ/w6f9cZI2tar5U=; h=Subject:References:To:From:Date:In-Reply-To:From; b=ESDHpImwUcGAb8FjVbYynxLrxvh4p/kRcHAIO58h2T4ybM8DLZJGGL10DkVtp/bR2 t4HqXFzXmbvMYTDR2zz5SWP3Vn8tr0wKSVA+h8Usn1mJNBBpkKWpbbFDQwi6AqEXDj vOHdZQmjcLuS4rTLfqn+vC8/CbsZ27Vajzcx6snM= References: <829e7169-d1b9-c971-94b4-4f661b5a2c8e@cs.tcd.ie> To: "ace@ietf.org" , lpwan@ietf.org, lwig@ietf.org, 6tisch@ietf.org, core WG , "tls@ietf.org" From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== X-Forwarded-Message-Id: <829e7169-d1b9-c971-94b4-4f661b5a2c8e@cs.tcd.ie> Message-ID: <53124783-0d5a-c531-0b1f-cd63a8a1c704@cs.tcd.ie> Date: Sat, 11 Jan 2020 20:37:02 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <829e7169-d1b9-c971-94b4-4f661b5a2c8e@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rwI2pelNHuJLfJh8CnnbmpJxwj1eSR2qo" Archived-At: Subject: [Ace] Fwd: lake wg jan 16th virtual interim X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2020 20:37:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rwI2pelNHuJLfJh8CnnbmpJxwj1eSR2qo Content-Type: multipart/mixed; boundary="RLM84vciukC4xZMWSkylzr4qp4ZwTdHmS"; protected-headers="v1" From: Stephen Farrell To: "ace@ietf.org" , lpwan@ietf.org, lwig@ietf.org, 6tisch@ietf.org, core WG , "tls@ietf.org" Message-ID: <53124783-0d5a-c531-0b1f-cd63a8a1c704@cs.tcd.ie> Subject: Fwd: lake wg jan 16th virtual interim References: <829e7169-d1b9-c971-94b4-4f661b5a2c8e@cs.tcd.ie> In-Reply-To: <829e7169-d1b9-c971-94b4-4f661b5a2c8e@cs.tcd.ie> --RLM84vciukC4xZMWSkylzr4qp4ZwTdHmS Content-Type: multipart/mixed; boundary="------------3A3AEBD3B471977F177AA9E0" Content-Language: en-US This is a multi-part message in MIME format. --------------3A3AEBD3B471977F177AA9E0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, The LAKE WG [1] has a virtual interim next week to discuss requirements. LAKE aims to define an authenticted key exchange mechanmism suitable for environments needed a more "lightweight" approach. If you're interested, please do join in. If you can't make the call feel free to raise issues in the github repo for the requirements draft or send mail to the lake list (or even to me in extremis:-). Details of the call and repo are in the attached. Cheers, S. PS: Sorry for the spam. This is sent to the lists of the set of WGs mentioned in the LAKE charter is my excuse:-) -------- Forwarded Message -------- Subject: [Lake] lake wg jan 16th virtual interim Date: Sat, 11 Jan 2020 20:31:49 +0000 From: Stephen Farrell To: lake@ietf.org --------------3A3AEBD3B471977F177AA9E0 Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" VGhpcyBpcyBhbiBPcGVuUEdQL01JTUUgc2lnbmVkIG1lc3NhZ2UgKFJGQyA0ODgwIGFuZCAz MTU2KQotLTJtcXU3Z2lhN2gyUVdqMGVHaDJVTUpKVnlVb25VUTVGMApDb250ZW50LVR5cGU6 IG11bHRpcGFydC9taXhlZDsgYm91bmRhcnk9IlI3VnhSTUJnamtaUVZ1UG0xNVFkNG1SZnVK UHU2SmRXTSI7CiBwcm90ZWN0ZWQtaGVhZGVycz0idjEiCkZyb206IFN0ZXBoZW4gRmFycmVs bCA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT4KVG86ICJsYWtlQGlldGYub3JnIiA8bGFr ZUBpZXRmLm9yZz4KTWVzc2FnZS1JRDogPDgyOWU3MTY5LWQxYjktYzk3MS05NGI0LTRmNjYx YjVhMmM4ZUBjcy50Y2QuaWU+ClN1YmplY3Q6IGxha2Ugd2cgamFuIDE2dGggdmlydHVhbCBp bnRlcmltCgotLVI3VnhSTUJnamtaUVZ1UG0xNVFkNG1SZnVKUHU2SmRXTQpDb250ZW50LVR5 cGU6IG11bHRpcGFydC9taXhlZDsKIGJvdW5kYXJ5PSItLS0tLS0tLS0tLS1FMTYxMjdDRUI4 QjM3MDE3NEI4NUYzNDkiCkNvbnRlbnQtTGFuZ3VhZ2U6IGVuLVVTCgpUaGlzIGlzIGEgbXVs dGktcGFydCBtZXNzYWdlIGluIE1JTUUgZm9ybWF0LgotLS0tLS0tLS0tLS0tLUUxNjEyN0NF QjhCMzcwMTc0Qjg1RjM0OQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9dXRm LTgKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogcXVvdGVkLXByaW50YWJsZQoKCkhpIGFs bCwKCk1hbGk9QzU9QTFhIGFuZCBJIGhhdmUgdXBsb2FkZWQgYSBkcmFmdCBhZ2VuZGEgWzFd IGZvciBvdXIKdmlydHVhbCBtZWV0aW5nIG5leHQgd2Vlaywgd2hpY2ggaXMgVGh1cnNkYXkg MTYwMCBVVEMuClN1Z2dlc3RlZCBjaGFuZ2VzL2FkZGl0aW9ucyBhcmUgdmVyeSB3ZWxjb21l LCBqdXN0IHNlbmQKdG8gdGhlIGxpc3QuCgpJbiBhZGRpdGlvbiwgRz1DMz1CNnJhbiBhaW1z IHRvIHRyYW5zbGF0ZSBzb21lIG9mIHRoZSByZWNlbnQKbGlzdCBkaXNjdXNzaW9uIGludG8g Z2l0aHViIGlzc3VlcyBvbiB0aGUgcmVxdWlyZW1lbnRzCmRyYWZ0IFsyXS4gWW91IGFyZSBh bGwgYWxzbyB2ZXJ5IHdlbGNvbWUgdG8gY3JlYXRlIGlzc3Vlcwp0aGVyZSBzbyB3ZSBjYW4g ZW5zdXJlIHRob3NlIGdldCBkaXNjdXNzZWQgbmV4dCB3ZWVrIG9yCnRoZXJlYWZ0ZXIuCgpD aGVlcnMsClMuCgpbMV0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvYWdlbmRh LWludGVyaW0tMjAyMC1sYWtlLTAxLWxha2UtMDEvPQoKWzJdIGh0dHBzOi8vZ2l0aHViLmNv bS9sYWtlLXdnL3JlcXMKCgotLS0tLS0tLS0tLS0tLUUxNjEyN0NFQjhCMzcwMTc0Qjg1RjM0 OQpDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3BncC1rZXlzOwogbmFtZT0iMHg1QUIyRkFG MTdCMTcyQkVBLmFzYyIKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogcXVvdGVkLXByaW50 YWJsZQpDb250ZW50LURpc3Bvc2l0aW9uOiBhdHRhY2htZW50OwogZmlsZW5hbWU9IjB4NUFC MkZBRjE3QjE3MkJFQS5hc2MiCgotLS0tLUJFR0lOIFBHUCBQVUJMSUMgS0VZIEJMT0NLLS0t LS0KCm1RSU5CRm85VURJQkVBRFVINFpQY1VuWDVXV1JXTzRrRWtIZWE1WTVlRXZaalN3ZS9Z QStHMG5yVHVPVTluZW0KQ1A1UE12bWg1Q2c4Z0JUeVd5TjRaMitPMjVwOVRqYTV6VWIrdlBN V1l2T3Rva1JycDQ2eWhGWk9taVM1YjZrVApxMElxWXpzRXY1SEk1OFMrUXRhRnE5NzhDUmE0 eEg5R2k5dTR5elVtVDAzUU5JR0RYRTM3aG9uY0FNNE1PRXRFCmd2dzRmVmhWV0p1eXkzdy8v MEYydHpLckVNam1MNVZHdUQvUTkrRy83YWJ1WGlZTk5kOVpGanY0NjI1QVVXd3kKK3BBaDRF S3pTMUZFN0JPWnA5ZGFNdTlNVVFtRHF0WlViVXYwUStEblFBQi80dE5uY2VqSlB6MHAyejNN V0NwNQppU3dIaVF2eXRZZ2F0TXAzNGE1MGw2Q1dxYTEzbjZ2WThWY1BsSXFPVnorN0wrV2lW ZnhMYmVWcUJ3Vis0dUw5CnRvOXpMRjlJeVV2bDk0bEN4cHNjUjJrZ1JncE02QTVMeWxSRGtS NkUwb3VkRm5KZ2IwOTdaYU55dVkxRVRnaFYKQjVVaXIxR0NZQ2hzOE5VTnVtVEhYaU9rdXpr K0dzNERBSHgvYTc4WXhCb2xLSGkrZXNMSDhyMms0THlNMmxwNQpGbUJLakc3Y0djcEJHbVdh dkFDWUVhN3J3QWFkZzR1Qng5U0hNVjVpMzN2RFhRVVpjbVcwdnNsUTJJczAyTk1LCjd1QjdF N0hsVkUxSU0xek5rVlRZWUdrS3JlVThEVlF1OHFOT3RQVkUvQ2RhQ0ovcGJYb1llSHoyQjFO dmJsOXQKbHlXeG41WGlIekZQSmxlWGMwa3NiOVNrSm9rQWZ3VFNaelR4ZVFQRVI4bGE1bHNF RVBiVS9jRFRjd0FSQVFBQgp0Q0ZUZEdWd2FHVnVJRVpoY25KbGJHd2dQSE4wWlhCb1pXNUFh bVZzYkM1cFpUNkpBajBFRXdFSUFDY0ZBbG85ClVZd0NHd01GQ1FtVUpnQUZDd2tJQndJR0ZR Z0pDZ3NDQkJZQ0F3RUNIZ0VDRjRBQUNna1FXckw2OFhzWEsrcUcKQ3hBQXBZSFdZZ0dPSUwz RzYvT3BrZWpkQWtRb0NWUUFLOExKVVNmNnZ6d29zdDRpVmZ4SUtjS1cvM1JxS05LawpyUmw4 YmVKN2oxQ1dYQXo5K1ZYQU9zRTkrek54WElEZ0dBN0hsdkpuaGZmbCtxd2liVmdpSGdVY0pG aENTYkJyCnNqQysxdVVMYVRVOHpZRXlFVC8vR09HUExGK1grZGVna0Uvc2VzaDR6Y0VBakY3 ZkdQbmxuY2RDQ0gzdHZQWloKc2RUY2p3T0NSVm9uS3NEZ1F6QlRDTXovUlBCZkVGWDQ0SFp4 NGcxVVFBY0NBNHhsdWNZOFFrSkV5Q3JTTkdwRwpudkdLOERjR1NtbnN0bDEvYTlmbmxocGRG eGllWDNvWTJwaEoxV0trWVRuNkFkdnJlazNVUDcxQ0t4cGd0UG1rCmQzaVVVei9WWmEwQ3Y2 WXhRWHNrc3BSRFZFdmRDTVlTUUJ0SlBRNHkyKzVVeFZSOUdJUVhlbndZcDlBUDJuaXYKVm9o K0lUc0RXV2VXbm52WU1xMDdyU0RqcTBuR2RqNDFNSmtOWCtZYjJQWFZ5WEl0Y2o1eWJFM1Qy K3kzcFNCRwpGRVpZSkd1YUw0Tnd0QkpGTU9kT3RCbVVPUGJldFMyOTcxRUwzSXp4YjdpYk9a V0R3ZXh2KzhSNlNXWWZQMXdWCk4zcDQ2UnlCUXVYcUpWOGNjRTExbTZ2dFpUR1NZZ25MVVVG Wk1SUVlIKzBod3VZZTBUM0FBMTh4RGRTWXNhOHYKb3ZDQ2QzbDVTNFVOeklNMlBNQ2hxR3JF ekthcFVwWmc3KzhBQ2N4UlUzYjlJaGQ3V1lqSitwUVBDb1dZS296dgp0RXZlbmJOcEUvZ292 Ty9FRDNCMTRlK1IyeWV2UlBqUnJzTjdQSnpTZjE1ZlFMdUpBUndFRUFFSUFBWUZBbG85ClVx QUFDZ2tRTHp5SE5vQmZqYUxyU3dmK01JSGJGUlE0TzVjbUxZUjVzSUJ5V2VsTjNTdVJOL2dX OHJwS285T2sKQ3o2QW44dVYvaUNYeTV0Tk1MenppMEJGbDhmMjJEd0JjQzVxeTlxbmxJQWRv Z1dhbTFxV29UQW9BRDh2ZUVxbQp1S2hZcnFKc0NjQXlOcktZbUswaFAzcnBIeHgxTHlTRG1L WVhtdy84cXRCWEtIVG91TW0rNXRTc3puaHlrUk1UCkFBcjJwN1BTYUhnbytoSVZhVy9yS1Nz cEhqRGhoWlMrRzltdE9aYWQxSUgyOU02RzFRMU5DTzBZd2U4a3JLTFEKSUFRbEZ4dGd2T3Fw UE9aTnplS0JhLytLYkU4VEdnTVdya09oQzhPZUVNNVBWemREaGxoRDlrUHpCL3BDS0RGNQpE b2ZKL1pScW5EcGJLUFEwYnNXMzhBT2lnM2tPYzBBMjdhd2lCRXczdXJxUjFZa0NNd1FRQVFn QUhSWWhCSDRYCkNnUmNoTTlHRGl0NW9CRHZlZG45ZzFNU0JRSmJ0eVNjQUFvSkVCRHZlZG45 ZzFNU0kvb1AvMEE5Sjlucm5CTXEKWnBtODU3bGZZV3crcnNoTEsrdHllUDRPUWVPcW5ERnZz OWplUHBjeUpMRzNERjJyNlZiVktQUXErQUU2VWY1aApjSkJERU42QmpFaFJQU2JMY3FHM0Ex Y3ovbk53bThyUG1OcCtvS2htYUJCUUd4d2NpTUxtemd5bnNEeWRualBwCk15RXMwNHp2c2Jz bDR2cnAyMDk1bzEwNWw4S2NycnhRcmlvRmpid3ZlR3dIUUs5YnhKS2h4OUQrZ0lrK01vdUIK dXI0NVVES1Raa01acnI5RkdydGt5WENHQXh2S2RjTkM1T2E4ejlzajFyY1VKZkcvT3BWQU1X aEFyZGxaYkZVUQp5b1g2cFUyWmIxQ1IycXBXQVZlckdTZkJobWZDeVN0akFScWFLeGxmdGpP K0JqM0pqNzNDcjVlcWVqM3FCNStWCjRCQ3NQanI0Ukx2VmJZVUNQc1JkeFdjK25CTGxmVllr UlVSdTIxZzFoRm01S0ZQamdVa3lvMXM0dmpVT1k4RHkKSSt4TEdGN2YvSWhVQkc2bCtWc3do cHd1N3lkYWxaa2VGaVB4NXhuYTVOZmJFWXh2c0lmNzFEdmlwR3ZJT2FIdgpYNGVnV29GZ204 bi85YzNyY014SnRwd0hQU3NVdDVkZ0xzeXU2VkUwSWJ2T0FjM2RON0NXSjM1NURWRkpxOVpn CjJZVmYwaXpTcHl5ekplR3Nna2ZqVzZ4cG1kdlp4dVQyVWNONEJUY202dllxdWVBU0dyYjNs Zmh6QzVncGVWc2MKL01vU2pUUzY1dk5XYnB6T05aV01adUxFRnJheFdKekMwSnJESzNOQ2Qw Vk4za3N0cUdrVmJVSWlZT25VbThWdQo0em9WTUxsR1d6SExJR29QUkcyblJlem4xWXlOZnli NWlRR2NCQkFCQ2dBR0JRSmJ4Y2ZsQUFvSkVHbzdFVGs4CnBLMWdFN1FML0FwQzVQNjhXNURy STE3ODdXSlZadjF1NHQvZzM5dlRyN1hlcjNVTVRWUWcxMHZwYTdwbXFPR2gKaklEekRNZzNQ ZTNLM003ZlZ6ZkFsVUExcXc2bmU0UkN1ZVZvUktwdWJlRjRBbFliTXIwSzZoTkNQanQ1dUF4 bQpiQlZ1ZWpLVGM2cHJ1NXJ2NWdLTDBuRGJyK1NuZnQ1eHQ3anVCTFNTaW13MC80MXNabmtq Q3hvOXJGL1JBL3Y2Cit1V3lLMTcxUkttc0VZdThmRnR3MWVxVU50L1hqNzkyVFVpeEUzcHhY aGVOdFF0WkdrLzlQM1c4M0NoaEc0RmgKNUVRc24wcEloOXdaSUFiTVJMcGdSS3lXODdmV0ha QzgvWUg4aDdhZmFydm45VGhsNXBGVWxkQ2UyMm1OSmo2SwpMQ2huMmFFSFFkK1BkWTFHQnBa RWNtTkVVUHVvdnd6YXRNMGg2NGhDelRtNDFlRHFSZmloWlZCVDdUYmZYUW52CjhyeXdhNDJN azc1NlJHenpFWmNRRWh3UVhaY01RVWZ4SVFRMlZ5Sm8wekczNlZkWlRRRjdURi80THo3LzNj SjUKNmpPSW0rZHdQWHR1K0Myd0FRdUQ0VVNPTHQ0SldQWXBxekRmSFlKSU5ELzQ5N1A5WjlT dVFlYWhyMmV6M0RSQgpnM3FzSEVqQlY3UXlVM1JsY0dobGJpQkdZWEp5Wld4c0lDZ3lNREUz S1NBOGMzUmxjR2hsYmk1bVlYSnlaV3hzClFHTnpMblJqWkM1cFpUNkpBa0FFRXdFSUFDb0NH d01GQ1FtVUpnQUZDd2tJQndJR0ZRZ0pDZ3NDQkJZQ0F3RUMKSGdFQ0Y0QUZBbG8rbzNjQ0dR RUFDZ2tRV3JMNjhYc1hLK3FPMEEvL1pzZlF6eVhyWmx1L2VFVjVqVTYyMHllTwpNM1A3U1cz QzNVUVlkQ2daL1RsdnhHZ0tvdzVvRFNYZ2pNaVV5cTljc0dxYlBCeGxEWVN4RlpITmVEVktZ SXVQCjJaSzI0dHc1azZkdVRoNCtzRndVdWFsVE1sY3AwekJDSXpuM2hSY3NSdnVQS0hmbDUr Nm9PaTAreHF4M2pYL3MKLzY5TC9mdkhtZFNLZXQ1TElVQXhvWWFaa1RDcnVGclBXYjAxdGdB bDVKRXhXa2htQ1k5OGlEK0VlaUlNQVdCagpNdzF4VitwMHVDd05iTjZYRHpjVG9LN3dzbSt0 QUlpV1V5M0RwUDYwYTZXYlZ3ZFYwSE50MldacTVVNUpkaDJrCjRTK3NOMkNuWWs0dFRXN2pI anNXYXJWM0ZMSVNDT09iQURadUI3bGpVNGtZZmR3WitXemVuWFk0TEdseEdRU2wKQWJsR2p3 WmU0RUlrQ1hBSlV0ekpob0ZVdUdhRi9QbFdqeHFWM1VGUmNnVEVSWlRpamd1VnlSRXJlOEdO RVJOZwp2RHhadnVYc3NFanZ6OVg1SmZjSVpESUpwZHpoTGlFSWo5bm9VYmZ4MVN6QjVLRFBR ajBPN2VsTUhhMTY3MS9yCndXY3BHci9NZlZQVE9pazRIN0Y4cmNWSmVsY2VaVHpDNHR2eWE3 TStqTTRmeUZXV3Q4WTRhdFRpeFVpUDdVOW8KNHVCWkNRMEd6dnNtRkE0WExxbjJwQTVyVml6 TVhuR2JHT2p1ZkFQL2VmRUo0dWwzcXZqWWU4eWU4RFhFRGpLQQp4by90dUhZdGsxOVhDaTgz UXpGaFdsczVUVCtYUWVWVE1FdlZxbzlXZWs4eW94bzY3cXZMS0txSWNHOWdpdlFkCjhNeFlO QWJOWWdTUHRrYmhaOFNKQVJ3RUVBRUlBQVlGQWxvOVVxQUFDZ2tRTHp5SE5vQmZqYUx6SEFn QWxXVDYKTlhFR3R3L3IxbWlLTkdjb3B6dnpJTFE5b0I4cktJOVU5RUw2dE9mL3kyVjVvWWVl L0d5UURiM1pkb1B4eFlZYwpKZitSeWlIMW5Nb3FVSVppWkphZjNiSlhpbkRaNStBZGZFKytV UjJOQnZxYU55QzZ1M3IyNGpvMUIvc2FnS2JZCnRXZ3NZdFJxSExENElXaTM3TVpyVnlqQnVG N3UxNFEwNyt1aGpxNm1YMk8vdEhwQ1l3L1E4MnRiZVRSUHlVZjEKV1FPQWZEMWtmQnBXOVB2 QXZhNUl3OUZXZVhwQ1hSend4bkNaaFlmR2ZxdHVTdzZDUEJZTGRiaWtxTUw2Rlo3RQpEdVRC Yi84dW0xd0s3WTliZ2VJUUMrQ1lqaFlCNVJYYTF0REpSYWIySnM0bHVDdlNSMHcvQ2dIdzI2 MjkzdGx2CmUyUTZVVHJtSHhQNVUyMkRsb2tDUFFRVEFRZ0FKd1VDV2oxUU1nSWJBd1VKQ1pR bUFBVUxDUWdIQWdZVkNBa0sKQ3dJRUZnSURBUUllQVFJWGdBQUtDUkJhc3ZyeGV4Y3I2dEpw RC80cnJJTEgrbWVQMDd2cng4d1c1ZVl1cUNpUApHWW5oL0NYeElGOGVMcmZiZTVkNFFSZ3Rx K3c2VWVRUE15ektSSVJpQ29CWEIyb0pMQlpIeXhCUHhabGczM2RUCk1yRUduOFFXS3gyaU51 ejlyWk1YeU9TV0ZldHVPMDFkL2FVUGQ1Qm5iTGJJeUs1b2Y4eENRbFhNNktIOGJjKzkKZ1E3 ZWRSOW1mTFRkdkJmMkZSNTIyaGc4QlJCTTFpbUtjM3ZPOHYzOStxSUhIUmp1aXd4QkJDQU9o SHRIUnNaWApyaXBTMHVGQTA3ZE00Nk9pL0U4b3NqeDZmUXQvbEg1ei9QTisyYWR4WVNyTFNB WGZyMW9EM1J4WU5odVdneUdGCkw2NC9WQ1FiMVlHamYwWjVNQlBuV205amdVb09ZNUs5ZU5T UzBMODNXZUpqbEY1K1EvV09nQityYjQ5UHJtMkQKRmVvOStTOWYyVjUzTGx6MVdJc3BYSmc2 ZituOWxtSEU5NE1mUWoxR0FIQ3pJMEZlTDE5bHZNK0xoRDhqSlNDYgpockMzK3lvYnl5L0FV T3M1WjNFK25qalgxRkYvVkNWQXM2aU9hNmkrWEcrWTFoaDNpcjJ5MWtja0o1YXVUMTBNClNV OEdFWnU5YXlVNE0zbzNOOXl4T2phb1AwTnVRNE1NTEwvbi91NHU5NEFlWmFIUE5CWG4vaFZm VlJSbXBSWHQKR0t2SnRGQUVwcEdFWWV6QitiTEtJbTZYbHBQa2hud1l6bGVMWjdBTUVjbzJD NlFNOFFQQjNnM0pwUzNzcVJoQQo1ckVQNGxMMTZCbWlqbUYrQ0hvUEUvendnS1piS3B5VkRx dklXNUlEZ3ZmSUMyWDRwYlpEUnZHSVVLYUdTQjQrCmtzWmdVVW5OeXZmUXIycDdqb2tDTXdR UUFRZ0FIUlloQkg0WENnUmNoTTlHRGl0NW9CRHZlZG45ZzFNU0JRSmIKdHlTYkFBb0pFQkR2 ZWRuOWcxTVNlS2tRQUptNDRqdDFrd0hnUWdlREJLZGpkdmwwQWpFMHhWRVF4cmlaNmxQLwps Ly8zNFlUMGF1RmZ6c1lJckNoU3BRWEFFdG9iQkFyNE9odzFVcytCWmUrSDVQOHZtNkxSdVB3 b3pDM1Nqd2ZYCjRJZWM4KzlvdDZ0SVZnNHNiZWREU2diL0NDRlZqc21JR2NRMVA3M0pMSlRC SjZteFlDVi9nbjNRQzZid0RPRm8KN2tEOUZESENqUk44WGZoSFE0UTljWXl0MDZ1RjMxcUcv YXVtZ1dZQzlnZUNHZ0F3aUhnd3hOWWI5R29KMGlaagpDUk93Yll2TFRjUWdzVlVXMmJUbXNW UjEzVVZLRHNkbDAyc1JWN3FjVllXNlIwYTNSYThLdWRYK250MjVINURSCkdkMzgyS1o1Vzhw eWRzeS92aVR2RDl6NnYwdWxDaEJZeEFlZEl2R0lDbHJoYnhsTEVQbUlnNEltVk9MR3FzVWcK Vm0zMko5NVdPakVrazRQRVoxMnhTREJ0d2hTSnFtSk5ib1dsZm13NDNLZEliWTh6TmhmZklP M042TzdGc2RHeAptcXlIZUxvVHBxWSt5U1ZVUHBidXlXOHVqbkkvSi8vKzZoZFRaOWRRc0VK UWxXbmdLdVdPUTVtYTU4TVBTTjg4CnpsbHNxaFpBRlFqTnhxbmtTekw2WlErdi9qdnVSUmUx NkI4MEFlTzU1RHNtYldzTXYvWUxMRDFtU2k3K0toeTIKRXRNQmhnb2pXd3JHTXZkTE42WDNt bnpOSkVzY1l5THhNOXRTaytpeVNQMnNMdGhLMEJWZ3BBekJTZGFmL2V6SQp6NjBQK25lSER6 dGVORmY4TW43bG1nWWsxYW12Wm9KMjlzNStuMkh3eHlSTDVkVk15TWR5UW1udHViYmN0ZnFy ClowdElpUUdjQkJBQkNnQUdCUUpieGNmbEFBb0pFR283RVRrOHBLMWduQ1lNQUpZNEZlSVlq bElYR2doRld6c0IKNGZZd0sxK2lhRnBVM2ZTdG81cWNycVZ0VlBqWHB3cWN6cUJXZVhHeVF4 aUIwa2FuNE9WQVh5ZEllYVA4RUF1RgpDQTdwYVAzczlTVExKQk8zS3Vya3d5UmtQVzV6bzBY N3hWcWFWVG9Sc1gyVWw5OEtWSm9IWVFEMUtkZXpFdHdsCnZwTndpaUJyNDJBWVI3NTFWbTZK QlZBYlFYdUZwQjNjOGJVVjBPa2tSeE5GdEw4LzJQaWVIYXI1OG41ZG50R2sKYlBsUGt6dGFo c0Zxa3RnYWNJZ1hIWDV2YVQrN1llZVoxRFdMT1lqR08wd05oa09TZXJvQ214d0pVaWtVN2pv QgpwODIzTDdyNUtmcHFXVFBwU0N6VnN0UUtaVUdtbW9FMXFDc3dZL1VkNXd2cDlTY2NwSUlM a1JYajByWlJ0Zm5FCjVNcEwzaGptdE56ZkRkOXFJc0p0QkpsU0IyaFp3QXNWbTFsK0VXTjlo RzN0cXlBNDNuaVVNeTJuNnE2OTBvZjMKYmVyU2lRK2t2WS9hQzlIeDhJK2JLek9WOS9KMlZV VHFmYVBaYTRVeTJyVlg1UTJwNjluL1BNajdtRWVyMHJDTAozajlWMTZKOWMrczBCU2tYb0tk dFlkQjBUV1ZoQmdVeWJkOXF0WWN3SFd2aFA3UXVVM1JsY0dobGJpQkdZWEp5ClpXeHNJRHh6 ZEdWd2FHVnVRSFJ2YkdWeVlXNTBibVYwZDI5eWEzTXVZMjl0UG9rQ1BRUVRBUWdBSndVQ1dq MVIKV2dJYkF3VUpDWlFtQUFVTENRZ0hBZ1lWQ0FrS0N3SUVGZ0lEQVFJZUFRSVhnQUFLQ1JC YXN2cnhleGNyNmpzYwpFQURFY0IwV1FFWm4yQWtyekRzMVJoTDBMcDZjWmkwQmlnb2ZrYmNH ZmRoSnlNU3MxOUMwZGh2bmNyQUZDbFZJCjYvVWR3M3lGdER5WXRPQ2YyVzNNM0ExSzYvUmZF aXpDTHpUc2RGSWhuaTlnT0pMbFVwWFZpUXRncmxzdGprN2gKcVZWM09vejRCbENxUzRjRzdy ZnFmNExRUVBwVEF1RlVFVjlJMjhGQlVCMmlycUMrdjRnVHlzSWdwTXcwYkExeQpCVTlzWDVq RS90Umt6cW51elpya3dpb2JEdFJGSjlxcCs3TzJKdGNZNEVzVnRMQXNhb2RKS2M1Y0Y4UjRP dkIxCm42NnZ4eGNnZzlFaDRKTldaNDd4c2FDbUFHbzFCY2IyaklZMzVPdGdBTDdnQ0dMUlNN S1R0QWFQeTEvZkVnSXEKaENsako5eDQwRmtuLzNyMkJYMjFXQzlIRlNQRlRCejJSbHVMUnp4 ZGd4T3JrWUs4RWlIVVBvRTViMUFFelpLdwoyQWJlWGZyNTdmNXpZc04zSXFmYlFMVWpNWXRV TjF3SzNQamIraWREOTcyd3lYTVd0OHVPemxJN2I5T2N1K25ZCm0yd2hCZkp2OVBtcDNRWVRt UHorTEI5bEg2NVZOVlVTeFNYVnI1aVdYTzNxeDFIdEVpR0Vxa3Bvck1RQ1RoM1QKNVVkM1B2 TVNSQkZGS05zOVdoSi9MeHorU1YzMFdMd0c2ZHI1bVFxbHpBaGI0UGhjL3pla1p5WFJkUy9v REtyQgpMVXVjUzM2Ty8vNDlKZXlSaTFRdk9meG5mbUlxUklBZi9rM1BvWUptVG81RTgyLy9y NVFqM1lHbFJ1NzhiYTBICkFyeHMrQUNENkFuRUhIY2Jzd3BidFZFS1l6bFN1MEFyMERjN3ZS V00vSXlRZElrQkhBUVFBUWdBQmdVQ1dqMVMKb0FBS0NSQXZQSWMyZ0YrTm9zSXNCLzlmLzI5 Rk5sYTNCSmZHSUVJRG5ocnFHRDBpOWJTYTg5U3FCZCsrdUcwNgpUUWdXNXdzcXROY3J3bjgx eVpUcTZYRTZpOVZ0RDRHS2ZxQzBkNEtaSnI5Ym5iZUQ4MWNJNjRWT2RMOHpKV0pzCjB2ajVF SVhDb2JLeVg3NEtiNHVlUFV5WnF3VDJRNzRJMTE2dS9Id0E5L0ZYc1BvNWlzYmg0WnFENHQw VkhwV2sKbWZxMUZQVDlhL0pQeVg0NnFLcUIyRmNlLzdReStTUVAxTmZrdVVsYmhVSC9KRzlh U1NZdmszbHpuTmlINDF4OQpNK0ZEbEwxMDZpdFhPdWJybDNvaTJmVDNmc1NlZHE3dXp0K0lW MERRRWVOYW9RQVV1d0VoZEI4SVdPTXFOMndvCkRqR1ZLSmZ0ZnNTV1k5aWxacm5EQk5EcnAw dlJxY3gzM0xVTWtJdzRkN2lCaVFJekJCQUJDQUFkRmlFRWZoY0sKQkZ5RXowWU9LM21nRU85 NTJmMkRVeElGQWx1M0pKd0FDZ2tRRU85NTJmMkRVeEpqdXcvNkFwSFNzVlRXRDRhMApINkZK MjNBOUZ0cHkrYVhaNHZZbHprU3Jmc24yRUNyRWZLM2xYUWgvdXp3akpVRFlaZUIxL0JRc0Za dGNZTlFPCkpTU0hiUTQ5QkZSTHdiMUovd0JaRzRiYm1ya0x4bk5iS0RLUXZ6eEVwY2xrTVcw RGowSjZvN2tHcm16SUdHcmgKQitKSk45OUFjaW5lSFJ1ZzhaU0ZJRVJSQ21pZ3hkaEFLVTBC RkQ3UCs1SE5IbHRTTDNERjFjMmZGT2YySnJnQgpLVm9FKzlSaE1aaldOYllldEZGTENralhi NVJwYXk5emVNbTFEeGZTVEdBbnVPd1VYVzZxcTRobmw1K1ZDLzQ4CmNlRFpFbExMZnU3UlFV WnY0NHBrU1RPV1pzK2lRb0ppSE1GSGs5d1BxeUIyVm9rMXlKMmEyajI3V2hYckpsUHcKblpi Z0pPNVJ5V0RHM3AvZVZtcGw1VXVjMmRzZklwUjE3S25BdVdwZ2hLNlYrY3lGbmNEb0dDbC9Z RzJNdm9vbApzVzA4RmlaaDNFajRkbkpqajI1VFprZUZHNzRKSkRYTHZNWXBKZlNCR25tRVR2 NERoY20yeFBxVk11RnVMMXFKCmxNYlZMck1vMkdYZW8wM096Tnl2YnMrdThXTElhR201aEM3 TjFDWFk4d1pzNGpvNk9KL2V4cHZuYzA3ZEV1d3MKNHpUM0FpV3YzbklvdVdSZVJTdFp5OVFr YXZEb2NxYnlQbWlsY2RQQ1lrNEJzT2x6cHd3Tzc0aE5HN2l5bDBLZApBbHdUeEdRN3kwckpv dTZIWWExVG1SaElFcjN2S3ZsVytKZlVVcnF0alhnc3VhY1RYbzQrSXJhMkpVRXJMMmNZCnpR TXExajRyMVp5aEZudXo5M3M3UnN4L053MCswWXVKQVp3RUVBRUtBQVlGQWx2RngrVUFDZ2tR YWpzUk9UeWsKcldDSnF3ditOTFZQRTRzRDRzREEyLzZFazdVc1JJVWtnK1MzOWZocVdzTGM0 cnR3L21EdW52OFVuNjFJM0swNApmWjJSeTRuRjloWk0wYTcxMFV2WEZiU3R2cnpSSk8zRUFB Y2RKUjlMVENkMTllOFVlcnVRYkllZTNZVDkxVTROCmtDOUpNcGVjZnE2Mi90ZU9BVTJlNVAz ZldZYUxzNVpYN3pDTHdXdUJjVzJsM1N5b2xqUWN6TTg1SGhKM1hIbSsKRm53UTZEOXhSbGUr bHZXVGN1QzlkMXlBeVViOElPb3NwY0wybEpUbXk4ZTNyNzlSMjRoUGxTQjRMRGUwd0VOOApB WGJhZ3JjQVFaand5YUh5V3hqSmJUd1owYjQzV0dkZklxWjFFbE9lb2ZmYmtldFBHUm1Xdng1 eFV2YjJBTEZCCkJkRVR6VjI3MGdzNVhESmdKMVNJSUtPeURBRHh3dnJvVGUyakQ4Qy84NDFl RXFsNVFTb3czcy9VM3pScWszbXQKdHRvOFF3L0RONzFhZWg2ZG1ZU3N2ZDJVanNIdy92b2ZP UFJCR3haTEVrS1RFdk1uaG1NVzloaUtQa1BpYStRZwpldllFMDIwcXBLU3hMRWRXQThucHJI d3htR2lETmVzQ2ZYU0M2dm0xcWZ5ajVnOEh6eFNja3E5WmFNaEtNQ283CnZ4ZmxVRUR1dVFJ TkJGbzlVRElCRUFENkRkSFFmTWF2OE9YZmhqVHRlb2FyT3JsSlRTZGNpNzI3eGllekdQdUIK SG1wdmNlQlJaZ1Jhc2RiYU1jNEhKZWUrUjkrNXgvbkxQQ3V5L0R4RHlJandJVWVKTmdjK2w3 TGpJOVdmcEhURAo4VTR4eGp2UjVNaTcrVG9RUVVPVU51elQwTzBweXV4UDF1WTNSZWhIRWhP VmZCWk81OWlwU2VaTDVpUUM2VDVNCnNLMVNLZnM1MXBMYTVUb0MxcmM4dEJKNHpabXhSQXla aVljL0FIMnVaLzZyWWpUVGtBbjFEVkk5RFlvMkQvekUKNGJHalhkSlc1cEtwaEZCMmxYM2RH NEk3T0RpKzVlMUg2QS9RcEN1Nno4L1prSVErOVQxeGNYL1l3aUZlQTdQYgpUdVcvZUlUYk1i STFlVjMrZnl5bTlhVDdSc2ZsbXAzMVp4dHIrc1p3R0daZjAwb29NQkZtcU9TLy9OVVEvVmYz CnZEVWV3MWg1UVUxeURhV1QzTkFwdmkrWFdQSDlUUHk2VE1mWkEyRlRoSGYxMXNYL2dEQmE1 SldRWmJwdFBFY20Kb2F6cGlLWnQ5MUNyRlBPYW9YRFBjay9RNjFkZm1yL29QaWtmQnlZbkFT SU0zT3dFdVhxeVE5SkRSZktyZW01cgorb0Evd3hXYjVqRUxFbEFoT3BueXFNTXZPaDd1ejFm b1Vzc0w4TUF2MlRHWG14cFZKOE51NGplNndmOTZaMjJmClEwRDM4enVkK0NLSDNiTVAzYXlY WEpCY2RQb0VOcnpGYldQNUZUZy80VFRESjN2T0FIWlI1aUN1bllnaHg4YjcKRmZhNFVia3ds RCtkaDhHaUlBdHZUNTFBYzBjTzBXYzBaamM1N3pQVXoxemxvTWJmK3piMUJzbjdEdUVRb3Fq MQpnd0FSQVFBQmlRSWxCQmdCQ0FBUEJRSmFQVkF5QWhzTUJRa0psQ1lBQUFvSkVGcXkrdkY3 Rnl2cXJDOFAvMXRGCjZUZVI4M3hENk1hc3FYeXJCandjTG16aWFGME1sa2o4ay9ZVWlaL2tu YjUzbjk3eFFuaDl5eFB2MFRUOFdwZmQKbjNCbXZxR3loOCtvdUhYOWpNT3hpUmtNZE5oSWF1 VllZLzhqbVJmQlNZV2NGa2ZNemRZYXN2ZEx0bVlKZ3gyNQoySEtURmRlT3Jzem9PaldqRXp3 bWgrdGNhM0FGTXUvbkIrKy9LQW1pNVVKVjd6c1o3dVlKNWptOTdMVjVTTGpOCkpJWFhNK2xI cUNEcmpEYURoTmN6bXExTENSbFU2L1dEanZrdXdhVmhaRzRsWHhNRHJ2S25YTWtqc2VRMm9L ancKcklkZlFNODZIMXo1SjMxbGZocW9wK29mMGNpbWNJc0JnU0NQdStoOTZMSHVBemVSQkNi REtlcXJmWnRBWkFHcwpva1JpbmE5OTQ3ZlJXeFhIaDNPNjZJTG1YS05SeHhXYkRrUHZZblFX VWF0OFNiU1REb1BXckRJR0RSSUF5cHFZCm8zcGNOMk9FMEMxY2hxZ0RaUXhrcis5a1laUXB1 cE9BTjJUUitmTTdKdmJPOWNvS0k4VXFvZzhDb3BvTWVEUWsKZDBZamNxbEIxRTBzdk9ESFR6 Y1NvUnpvZ0RCWURxTkxQN3FWa05YcGNPQVhTVmlvQmdpU0RmN281UmRTL3FtVQp5WEJJZXE2 STV6OHhCY2QrQlEvbi85RnJrbTZLN0lLUDNuZ1VQNHdFb2lQeDVaRTUrZlBJU2NHbVZVY1pJ TWhrCnZNdmVtOVhYaDF5eWhxTjE0Z2ZqbUx3UEdkV2JyZ0c4UVVlMHMyV2VXSXlzczZ1VGl5 RitaYkpTbzJYT0tWYzMKWUZNVlVVZmd5dWRxQVYxd1dkWmluVWsrSDNwa3FPS29IQXkvOGZT VAo9M0RZelFZCi0tLS0tRU5EIFBHUCBQVUJMSUMgS0VZIEJMT0NLLS0tLS0KCi0tLS0tLS0t LS0tLS0tRTE2MTI3Q0VCOEIzNzAxNzRCODVGMzQ5LS0KCi0tUjdWeFJNQmdqa1pRVnVQbTE1 UWQ0bVJmdUpQdTZKZFdNLS0KCi0tMm1xdTdnaWE3aDJRV2owZUdoMlVNSkpWeVVvblVRNUYw CkNvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vcGdwLXNpZ25hdHVyZTsgbmFtZT0ic2lnbmF0 dXJlLmFzYyIKQ29udGVudC1EZXNjcmlwdGlvbjogT3BlblBHUCBkaWdpdGFsIHNpZ25hdHVy ZQpDb250ZW50LURpc3Bvc2l0aW9uOiBhdHRhY2htZW50OyBmaWxlbmFtZT0ic2lnbmF0dXJl LmFzYyIKCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tCgppUUl6QkFFQkNnQWRGaUVF VzdXbTZsZGwwc1dHUEs0bldyTDY4WHNYSytvRkFsNGFNTFlBQ2drUVdyTDY4WHNYCksrcDlM dy8rUEdDcWdoQzl6dE5BZjRoSk5TeUtvUms3ampWaFdmSS9mTWVLRnFPcGt3WkZCVUpNQllr bDdYMFEKOGw4TGkydVlqcWttQ0psUGZCa3ZOOVBXeEtNU3FGQ3kxUjJhNlRkMmo2N1RyVENR T2FDOTJIVWNKSFNIVFAwbwo2eHorTUQrYzAvWXhJOXRnY292U1lkbmVzaXV4eTFkYUxEUy9m aVFTaThBMGFyMEduQUlaaHpvMXJPV1pEc3Y3Ci9odWpjTmQ5ZXNlYzVjSDNWVFpEWUJ2MHpK bHRKRUpHcEhPVUR2N2k1WWszWlZUeVVUQUZpRVJBSkRIVVdqaEQKWXQzcElqSXlpZ3NMdGZO MTQ5Rm1NUmVDZG5CV292N0NobXR4enNCcitvSXRuc21QalJRSjBGa3A5Y1lXK1YvMwpzeWpN Q3F3MmNVdU40bmE5YThBRDFBM3lCamUvUTdRdTZuMEVvalJnVWo5bGRaanBvRXZiNkdDby9F SGVITHFDCnY2OG9JMGJSTzIreHZ2YzZsNDU3Z2Zscmg5SUZ4SG1lb2NBRVdXVTU3MGZ4Z2xy TnRzNTd2b25ieEcwWVpwRFIKSndSRkJ3RGg0TlhibWd1S3ZIR3BXVkE5QS9ndW1OdWVEU21U bGZjdkNvbVh6MUNkeWIxUGNxaDhEWmU3TUtuTwpzUVlacXREMXpZdjNFZkNqMVhpRmZPOUp4 WFJuRVlEMVpTdDczZUdOaFc1RW14cXkyZ2dYNkxNQWw4S2ZFN3dWCldiRUFkYlM0a0x5WmxF emFRSmtDRXZQaUpMY2F5NkJuTkNkWU96Ylgzb3FNK05QejRscmtVdmZia3FkR0pUK28KR01v VkJiTWluSituVXRxWitZbmt6M2JoQWMwS1draWhEcmtTMmRMQUtWOVRVaTJPeVhRPQo9N3dS YQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0KCi0tMm1xdTdnaWE3aDJRV2owZUdoMlVN SkpWeVVvblVRNUYwLS0KCgo= --------------3A3AEBD3B471977F177AA9E0 Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" LS0gCkxha2UgbWFpbGluZyBsaXN0Ckxha2VAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9sYWtlCgo= --------------3A3AEBD3B471977F177AA9E0 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------3A3AEBD3B471977F177AA9E0-- --RLM84vciukC4xZMWSkylzr4qp4ZwTdHmS-- --rwI2pelNHuJLfJh8CnnbmpJxwj1eSR2qo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl4aMe4ACgkQWrL68XsX K+rXgA//XuDb1FBy1WZ8cmlO8yB8uO6Ty1QJxRBoKhjWqdovQaXKtP8+LUaxeka9 eNWcy2h0F9RzShgtm91SEyGt/7pcBPE9q9hWPJb43m7xGutCshSTOkjiVXnqOXqq YstVU9RquReuhU6VqcorhElKFNfbu5WkKsXAPyQoC0NMWX8gexp+Jz8wQoN8ujG7 dgUjC5PaTFR6cu66cuu+i4PvBeU2fYsMuU1E272yES9ps/32+u0fJLl9YxjprKeu vmHMTyjmln6JerSk5lOMXntrAq1Zqmz+uVqKC985YK0RRrhGgu2vH6aWI0+CyBxo roDo8BNmZX9ASTDXek6xKRfJFTDeY1TKKnghDkIftSITKuEsyeKJYPkUU7RlL5FQ waPhzwpuX4PATnCjuopS9cxHYCVh/FSvkHsidldAJokaC/hxb6Gl0CUYtNdmGC+R BnbHsXjY1uhbzqfrRCm0rIaTs7PQILiTdSrCe4MX+b/+EVQQCYQha1gt0+zw2MZ9 qjM+SPKcLE23NH4NNxc1/G6beU5fzvId+naOVAuj2zEwNY3CwONwPCfjmEUSpo4y sKDazSGpvSenUx7fwdVI28Cg+nHyR3YBdcFK3SjKkOLkVnCnRdjD6xcqjG2f29IQ 7xfxV7oQxr7fd4Vw9bTVuUm5o04oXFKo2TVZYdRYNrTKBOjhYLo= =TfZK -----END PGP SIGNATURE----- --rwI2pelNHuJLfJh8CnnbmpJxwj1eSR2qo-- From nobody Sat Jan 11 18:38:58 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB8A12009E; Sat, 11 Jan 2020 18:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPv_zQcSElhu; Sat, 11 Jan 2020 18:38:54 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1DFC12007C; Sat, 11 Jan 2020 18:38:53 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 11 Jan 2020 18:38:47 -0800 From: Jim Schaad To: 'Marco Tiloca' , CC: References: <01b401d59f2e$ff406560$fdc13020$@augustcellars.com> In-Reply-To: Date: Sat, 11 Jan 2020 18:38:45 -0800 Message-ID: <000001d5c8f1$6b0c7630$41256290$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQI4jLavukz0j9XyZB28pLOfckduegK6NarEpwrvSdA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] remarks on draft-tiloca-ace-oscore-gm-admin-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2020 02:38:57 -0000 -----Original Message----- From: Ace On Behalf Of Marco Tiloca Sent: Wednesday, January 8, 2020 8:08 AM To: Jim Schaad ; = draft-tiloca-ace-oscore-gm-admin@ietf.org Cc: ace@ietf.org Subject: Re: [Ace] remarks on draft-tiloca-ace-oscore-gm-admin-00 Hi Jim, Thanks a lot for this review! We have been working on an updated version accessible at [1], which is = already taking into account your comments on CoRAL. Please, find below inline some more replies and open points. Best, /Marco [1] https://gitlab.com/crimson84/draft-tiloca-ace-oscore-gm-admin/blob/v-01/d= raft-tiloca-ace-oscore-gm-admin.md On 2019-11-20 00:13, Jim Schaad wrote: > This is just going to be a high level review on how things are done=20 > rather than a detailed review on each line of text. > > 1. - Go and read that CoRE Pub-Sub update document - you know the one=20 > that Klaus and friends have not managed to get written since the model = > proposal was done way back when. Yes, we are now relying on an akin interface, along the lines of the now = published draft = https://datatracker.ietf.org/doc/draft-hartke-t2trg-coral-pubsub/ > > 2. Re-write this to use CoRAL - Yes I know that this makes another=20 > dependency on getting it published from the CoRE group, but I don't=20 > want to do things multiple times. We have now also added examples in CoRAL, for all the interactions = between Administrator and Group Manager, now also extended with FETCH = for filtered retrieval. > > 3. I think that this document really needs to be able to be used with > HTTP/JSON as well as CoAP. If you can get the JSON version of CoRAL = from > Klaus then this falls out without any work. We are now saying the CoRAL examples are in text format, but they are in = CBOR or JSON on the wire, with no particular additional effort. Is this = enough? Sounds good. > > 4. Are you making it a requirement that the group name be the same as = > the group identifier assigned by the "group_name" parameter? If so=20 > then having some type of title and description would seem to be almost = mandatory. They are in fact the very same thing. The "group_name" parameter = specifies the group name, as intended to identify the OSCORE group both = by the administrator and the joining nodes in the other related = documents. We can use only "invariant name" rather than "invariant = identifier". Are we missing something? If so, what do you suggest we = should give a title and description to? If you are looking at "group_name":"GP00123", then as a configuration = agent it is difficult to know just what this group is supposed to be. = In this case some type of title or description helps to figure that out. > > 5. There needs to be some parameters around pointing to the correct=20 > AS and so forth. The management API may reject because it does not = trust the AS. > Don't assume that this is a single value for the AS either. This is good and also aligned with other related drafts. If we interpret your suggestion correctly: 1) The POST request to /manage may specify also an optional 'as_uri' parameter, with the link to a suggested AS. The GM may accept the = suggestion or not. If not, it has to think of an alternative AS, as = valid issuer of tokens for joining that group. 2) The GM must have one more parameter in the group configuration with = the effective AS URI, i.e. either one provided by the administrator and = accepted, or one otherwise decided. Do you think of any additional related parameters to be included in the = POST request, other than 'as_uri'? Perhaps the public key of the = suggested AS if applicable? Do you think the suggestion in the request should actually be a list of = AS, out of which the GM may pick up at most one? I have put something into draft-schaad-core-reef which starts thinking = about this. I think that we need to sit down and do a brainstorming = session to figure out what items should/should not be put into such a = structure. > > 6. You are missing a lot of management detail on the POST to the=20 > group node. Some of the things that are missing would be: > a) Is the group active or inactive We can have one more parameter on the group-configuration resource for = this. We are interpreting active/inactive as follows. Ideally, upon creating = the group, the request can specify the initial status as active or = inactive. Upon later updating the group by sending a request to the = group-configuration resource, the administrator can change the status = (or read it through a GET). Then the active/inactive status has two parallel scopes: 1) one scope is for the GM alone, i.e the GM would allow the joining of = new group members only if the group is set as active. 2) when the group is set as inactive, the current group members should = refrain from sending and should not expect receiving any message = protected with that group key material. However, there is no way to = actually force them to. In support to scope (2), when the status changes to inactive, the GM = should inform group members about that. To this end, the = group-membership resource intended for group members would also include = a parameter reflecting the group status and aligned in value with the = one in the group-configuration resource. Then, there are two ways to = inform the group members of a status change. a) A way is to have the group members observing the group-membership = resource (that they may have been doing already anyway for = notification-based rekeying). b) A second way is for the group members to have a dedicated local = resources for this (and other) kind of control communication (e.g. rekeying). This is something we are also considering in ace-key-groupcomm(-oscore) for receiving individual rekeying messages. In either case this would require either: i) each node to provide the GM = with the URI to such local resource, in the join request; or ii) the GM = to include in the join response to each joining node a same multicast = address targeting a local resource that that node has to create to = receive control messages. I don't remember for sure what I was thinking about when I wrote this. = I think that I was more interested in if one can or cannot join a group = when it is inactive and what happens. If you set a group to inactive, = are all members of the group removed or does the group just stop issuing = new keys? > b) How does the server react if you change a the content encryption=20 > algorithm, is this a simple re-key operation or is it more complicated An easy answer would be rekeying the group, just as for any other = triggering reason. I agree this should be mention in this draft. However, I think a more elaborated description of what happens if the = algorithm is changed (regardless why and how) should be actually better = given in oscore-groupcomm (the what) and in ace-key-groupcomm-oscore = (the how). Punting to a different document is fine as long as it really is there. = However, this is the place where it appears to be changed by an external = source and thus seems to be a good place to talk about it. > c) How does the server react if you change the signature algorithm? =20 > This would seem to be a much harder thing to do if the group is not=20 > empty or not active as everybody is going to need to re-join. Right. If the signature algorithm changes, the current public keys may = be not compatible with it any longer. We see the following possible = ways, assuming the current group members have learnt of the new = algorithm in use. 1) The hard way, i.e. everyone leaving and re-joining. 2) A more lightweight way, i.e. relying on yet another operation for = current group members on the GM, to upload a new public key consistent = with the new algorithm. This would require to proof possession of the = corresponding private key, as it is done upon joining. Probably, in this = case, this can happen like we do in the Group OSCORE profile of ACE = between the Client and the AS, see the bullet point on = 'client_cred_verify' at [2]. And again it looks like details on the way this is done fits better in = other documents. [2] https://tools.ietf.org/html/draft-tiloca-ace-group-oscore-profile-01#sect= ion-3.1 See comment above. > d) Other parameter that are changed may be just as bad as changing the = > signature algorithm - how the re-key is done jumps immediately to = mind. Yes, changing HKDF/Alg results in what discussed two replies above; = changing anything else (thus related to signatures) results in what = discussed in the reply above. Much of this may go to say that changing this parameters kicks everybody = off the group and restarts from scratch. > > 7. Is there currently any way for a KDC to signal to all of the=20 > members that have joined that the key group no longer exists? A=20 > DELETE would seem to indicate the need to be able to do this. Right, the DELETE of a group-configuration resource would trigger = something like this. The current resource maintaining on the GM consists in: destroying both group-configuration and group-membership resource, = then reply to the Administrator. That said, a possible extension to also inform current group members is = akin to what we describe above about signaling that the group has moved = to inactive state. That is: i) if group members observe the group-membership resource, a 4.04 = notification is sent to them, upon deleting that resource. ii) if group members have their own local resource to receive control = messages from the GM, a control message can inform about the deletion of = such group-membership resource. This would be particularly convenient to = be sent over multicast. This method (ii) would actually require the GM = to send these messages to the group members first, and only afterwards = actually delete the group-membership resource, in case information such = as the destination addresses and URIs to consider are stored as part of = the group-membership resource itself. A group member can of course discover what happened at any time, just by = sending any type of request to the deleted group-membership resource and = getting a 4.04 response back. The actual difference between an existing inactive group and a deleted = group is that the latter has no way back, and would need to be = re-created from scratch on the GM by the Administrator. Also could say that you can only delete a successfully inactivated = group. Jim > > Jim > > > -- Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se From nobody Sun Jan 12 17:38:40 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92D7112001E; Sun, 12 Jan 2020 17:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.793 X-Spam-Level: X-Spam-Status: No, score=-0.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZHS8tA1ASW9; Sun, 12 Jan 2020 17:38:38 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74A40120071; Sun, 12 Jan 2020 17:38:38 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 12 Jan 2020 17:38:14 -0800 From: Jim Schaad To: CC: Date: Sun, 12 Jan 2020 17:38:12 -0800 Message-ID: <003f01d5c9b2$1fe439b0$5facad10$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdXJrx9q+1Bfi7elThW0vWlpUZPgzg== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] draft-ietf-ace-mqtt-tls-profile - Validating a subscription is in scope X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2020 01:38:39 -0000 I have run across an interesting question for doing validation of subscriptions that I would like to get an opinion on. When doing a publish, there is not an issue. One simply takes the set of values in the scope field as topic filters and checks the publication topic against the set of permissible publication topic filters in the scope. When doing a subscribe, there are four distinct cases that can arise: 1. The subscription is for a single topic and either is or is not successfully matched against the scope topic filter. 2. The subscription is for a topic filter and it is identical to the scope topic filter. 3. Both are topic filters and are not the same. Is one supposed to do some type of subset matching on the two filters or does one always say that this is not a match. This is not addressed in the MQTT document and I am not sure where it would be addressed. As an example: Scope value is subscribe_sport/# Subscription topic is sport/tennis/# The second is clearly a subset of the first and thus it would seem logical to include it, but it gets more complicated if one instead asks for Subscription topic is sport/+ In this case the two wild cards are not the same value. Jim From nobody Mon Jan 13 10:01:48 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016A912088C for ; Mon, 13 Jan 2020 10:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lU0A2rIm5gjd for ; Mon, 13 Jan 2020 10:01:39 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD8F8120877 for ; Mon, 13 Jan 2020 10:01:38 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id m26so11113179ljc.13 for ; Mon, 13 Jan 2020 10:01:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mA5UK0jVOT30/B0E//GIzMGFTLOicC7w8fvBHLl0VUo=; b=PQnsTDBYHaabHEZvFMDm1eFq2nj6iKxhXosuiOwubKSnXly3FjT9J1ERO7E3gHSQ2J 8qhcTv9wwJ+78Czsqa7LXHF5eqGnXxwIWgq4qPjTKB7hKaNksak7fRdzFwrMCer2Bl9W /Go8evpROjbMvkKOw3mvzsa3c5+fhGNWFA1IvFizH7/XBIAwLrZ0f2hoondhffaRtmjX J/3ncMsUf0sFfQ94e5wYjScLTjXvMHMuXJWNfPTI/B6IX6Mo97RhK5xe6Ul+GpxFScyj YRNMMB8eKQM4ay7v4xXAHJbdos1ElyFL4yALjZQSosgNKrbgiKmXm9uvreRFfoVJI+NS IZ0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mA5UK0jVOT30/B0E//GIzMGFTLOicC7w8fvBHLl0VUo=; b=K0agupRmaa4kzG2YdxEN+bguXcQrNXoMwsDz6imz8Q9bIHwanvhKZENZ4MgHAVkBIG Tg/6r8JDJHVLpQPeLL+qnOI2nlYG6zWJ3V5U5RkTvW0gPhoCrgHIrcwlPrDSXN9LLuXA 5ldien+unpRlYk8PwcwrE/peoB1dJNYyQ8XSeYts+0wLeNp2Vo5BeLesFX4zLo4QFaTA mt3S2dAT3IoopfFCxf7XKfS0KDyotFQRvZB2MgJ7cACuwOo98kCDktjfsnUn64J7BV8x qYa0hBbnPl4EnifqptO55QrP14tNSQWYTiTOhZyM3b1aOAFscECghOXOaqyKHxR5DExy qPyQ== X-Gm-Message-State: APjAAAV6h6qnnO//jtiEOtjvox9owow2WXCVy+xMInW+KOofsc8EES+0 YiXIwqoYMDniUMVnFk3qmuL7rpjzPtAVc0BDQrasZmxVXySwhLucZcqGtdCpsa0W8UpT7Pj/RMa 9vxlV1gItAGY= X-Google-Smtp-Source: APXvYqy2La082688Tw09+b6LYeoTYoXNbPZO1yva+lJPNlicq1XW5+nqVjY6tl7NobV1b8jbt4pnuQYGqpa7xb3KMFE= X-Received: by 2002:a05:651c:2c7:: with SMTP id f7mr11037482ljo.125.1578938496704; Mon, 13 Jan 2020 10:01:36 -0800 (PST) MIME-Version: 1.0 References: <4a5177af-a442-f109-f620-0ae91953eb63@gmx.de> <2616175d102b4c19a60c6a79d4256b5e@combitech.se> In-Reply-To: <2616175d102b4c19a60c6a79d4256b5e@combitech.se> From: Brian Campbell Date: Mon, 13 Jan 2020 11:01:10 -0700 Message-ID: To: Seitz Ludwig Cc: Ludwig Seitz , Roman Danyliw , "oauth-ext-review@ietf.org" , Daniel Migault , Jim Schaad , Benjamin Kaduk , "ace@ietf.org" , "drafts-lastcall@iana.org" Content-Type: multipart/alternative; boundary="00000000000037f8ea059c094483" Archived-At: Subject: Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2020 18:01:42 -0000 --00000000000037f8ea059c094483 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Ludwig, On Sat, Jan 11, 2020 at 8:20 AM Seitz Ludwig wrote: > [snip] > > > > *From:* Ace *On Behalf Of *Brian Campbell > > > [snip] > > > > So in -09 the "cnf" Introspection Response Parameter was the following th= e > syntax of the "cnf" claim from PoP Key Semantics for CWTs > [ID.ietf-ace-cwt-proof-of-possession] and in -10 it's following the synta= x > of PoP Key Semantics for JWTs [RFC7800] transitively via > [I-D.ietf-oauth-mtls] reference. I think I understand that the two PoP ke= y > semantics documents are conceptually the same or similar. But I don't kno= w > that the syntax is the same? Figure 5 > is > pointed to for mapping between CBOR and JSON but it only has mappings for > the main top level parameters. Maybe I just don't get it or am missing > something... > > > > [LS] No you are not missing something, I just got sloppy trying to do a > quickfix. > > > > Background: The reason for defining both JSON and CBOR-based interactions > is that you might have a powerful client communicating with a constrained > RS. The client does vanilla OAuth interactions with the AS via the token > endpoint, but is served a CWT and associated ACE parameters (cnf, > ace-profile, =E2=80=A6) for interaction with the RS. > > The pop-key should decode to the same binary representation regardless of > whether it came in a JSON or CBOR wrapper. > Okay, so noting that there is cnf content that doesn't decode to a key, I suppose I'll just take it on faith that all the relevant or expected usages involve a key that can be represented in both CBOR and JSON. > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000037f8ea059c094483 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Ludwig,

On Sat, Jan 11, 2020 at 8:20 AM Sei= tz Ludwig <ludwig.seitz@combitech.se> wrote:
[snip]

=C2=A0

From: Ace <ace-bounces@ietf.org> On Behalf Of Brian Campbell

=C2=A0

[snip]

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0

So in -09 the "cnf" Introspection Response= Parameter was the following the syntax of the "cnf" claim from P= oP Key Semantics for CWTs [ID.ietf-ace-cwt-proof-of-possession] and in -10 = it's following the syntax of PoP Key Semantics for JWTs [RFC7800] transitively via [I-D.ietf-oauth-mtls] reference. I think I unde= rstand that the two PoP key semantics documents are conceptually the same o= r similar. But I don't know that the syntax is the same? Figure 5 is pointed to for mapping between CBOR and JSON but it only ha= s mappings for the main top level parameters. Maybe I just don't get it= or am missing something... =C2=A0

=C2=A0

[LS] No you are= not missing something, I just got sloppy trying to do a quickfix.

=C2=A0

Background: The= reason for defining both JSON and CBOR-based interactions is that you migh= t have a powerful client communicating with a constrained RS. The client do= es vanilla OAuth interactions with the AS via the token endpoint, but is served a CWT and associated ACE parameters (cnf= , ace-profile, =E2=80=A6) for interaction with the RS.

The pop-key sho= uld decode to the same binary representation regardless of whether it came = in a JSON or CBOR wrapper.


Okay, so noting that the= re is cnf content that doesn't decode to a key, I suppose I'll just= take it on faith that all the relevant or expected usages involve a key th= at can be represented in both CBOR and JSON.
= <= blockquote class=3D"gmail_quote" style=3D"margin:0px 0.8ex;border-left:1px = solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left= :1ex;padding-right:1ex">

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000037f8ea059c094483-- From nobody Mon Jan 13 10:38:03 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006AB120A42; Mon, 13 Jan 2020 10:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSZB_ywwfpos; Mon, 13 Jan 2020 10:37:59 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 157B6120A48; Mon, 13 Jan 2020 10:37:59 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 13 Jan 2020 10:37:51 -0800 From: Jim Schaad To: 'Brian Campbell' , 'Seitz Ludwig' CC: 'Ludwig Seitz' , 'Roman Danyliw' , , 'Daniel Migault' , 'Benjamin Kaduk' , , References: <4a5177af-a442-f109-f620-0ae91953eb63@gmx.de> <2616175d102b4c19a60c6a79d4256b5e@combitech.se> In-Reply-To: Date: Mon, 13 Jan 2020 10:37:49 -0800 Message-ID: <006a01d5ca40$913c3f20$b3b4bd60$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006B_01D5C9FD.831B4910" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEhd6Yle2bwoestBETa2w8Xfe67igHXMmInAunJ6fMCAFODFgH28139AnlL6EWo+AUhkA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2020 18:38:02 -0000 ------=_NextPart_000_006B_01D5C9FD.831B4910 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Brian, =20 If it does not work then I should know by the end of next week. I am = trying to merge my JWT and CWT token issuing code in my ACE OAuth server = right now. =20 Jim =20 =20 From: Brian Campbell =20 Sent: Monday, January 13, 2020 10:01 AM To: Seitz Ludwig Cc: Ludwig Seitz ; Roman Danyliw ; = oauth-ext-review@ietf.org; Daniel Migault ; = Jim Schaad ; Benjamin Kaduk ; = ace@ietf.org; drafts-lastcall@iana.org Subject: Re: [Ace] Requested review for IANA registration in = draft-ietf-ace-oauth-params =20 Thanks Ludwig, =20 On Sat, Jan 11, 2020 at 8:20 AM Seitz Ludwig > wrote: [snip]=20 =20 From: Ace > On = Behalf Of Brian Campbell =20 [snip] =20 So in -09 the "cnf" Introspection Response Parameter was the following = the syntax of the "cnf" claim from PoP Key Semantics for CWTs = [ID.ietf-ace-cwt-proof-of-possession] and in -10 it's following the = syntax of PoP Key Semantics for JWTs [RFC7800] transitively via = [I-D.ietf-oauth-mtls] reference. I think I understand that the two PoP = key semantics documents are conceptually the same or similar. But I = don't know that the syntax is the same? Figure 5 = = is pointed to for mapping between CBOR and JSON but it only has mappings = for the main top level parameters. Maybe I just don't get it or am = missing something... =20 =20 [LS] No you are not missing something, I just got sloppy trying to do a = quickfix. =20 Background: The reason for defining both JSON and CBOR-based = interactions is that you might have a powerful client communicating with = a constrained RS. The client does vanilla OAuth interactions with the AS = via the token endpoint, but is served a CWT and associated ACE = parameters (cnf, ace-profile, =E2=80=A6) for interaction with the RS.=20 The pop-key should decode to the same binary representation regardless = of whether it came in a JSON or CBOR wrapper. =20 Okay, so noting that there is cnf content that doesn't decode to a key, = I suppose I'll just take it on faith that all the relevant or expected = usages involve a key that can be represented in both CBOR and JSON.=20 CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. ------=_NextPart_000_006B_01D5C9FD.831B4910 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Brian,

 

If it does = not work then I should know by the end of next week.=C2=A0 I am trying = to merge my JWT and CWT token issuing code in my ACE OAuth server right = now.

 

Jim

 

 

From: = Brian Campbell <bcampbell@pingidentity.com>
Sent: = Monday, January 13, 2020 10:01 AM
To: Seitz Ludwig = <ludwig.seitz@combitech.se>
Cc: Ludwig Seitz = <ludwig_seitz@gmx.de>; Roman Danyliw <rdd@cert.org>; = oauth-ext-review@ietf.org; Daniel Migault = <daniel.migault@ericsson.com>; Jim Schaad = <ietf@augustcellars.com>; Benjamin Kaduk <kaduk@mit.edu>; = ace@ietf.org; drafts-lastcall@iana.org
Subject: Re: [Ace] = Requested review for IANA registration in = draft-ietf-ace-oauth-params

 

Thanks Ludwig,

 

On = Sat, Jan 11, 2020 at 8:20 AM Seitz Ludwig <ludwig.seitz@combitech.se> = wrote:

[snip]

 

From:= Ace <ace-bounces@ietf.org> On Behalf Of Brian = Campbell

 <= /o:p>

[snip]

  =                  =

So in -09 = the "cnf" Introspection Response Parameter was the following = the syntax of the "cnf" claim from PoP Key Semantics for CWTs = [ID.ietf-ace-cwt-proof-of-possession] and in -10 it's following the = syntax of PoP Key Semantics for JWTs [RFC7800] transitively via = [I-D.ietf-oauth-mtls] reference. I think I understand that the two PoP = key semantics documents are conceptually the same or similar. But I = don't know that the syntax is the same? Figure 5 is pointed to for mapping between = CBOR and JSON but it only has mappings for the main top level = parameters. Maybe I just don't get it or am missing something...   =

 <= /o:p>

[LS] No you are not missing something, I just = got sloppy trying to do a quickfix.

 

Background: The reason for defining both JSON = and CBOR-based interactions is that you might have a powerful client = communicating with a constrained RS. The client does vanilla OAuth = interactions with the AS via the token endpoint, but is served a CWT and = associated ACE parameters (cnf, ace-profile, =E2=80=A6) for interaction = with the RS.

The pop-key should decode to the same binary = representation regardless of whether it came in a JSON or CBOR = wrapper.

<= p class=3DMsoNormal> 

Okay, so noting that there is cnf content that doesn't = decode to a key, I suppose I'll just take it on faith that all the = relevant or expected usages involve a key that can be represented in = both CBOR and JSON.


CONFIDENTIALITY NOTICE: This email may contain = confidential and privileged material for the sole use of the intended = recipient(s). Any review, use, distribution or disclosure by others is = strictly prohibited.  If you have received this communication in = error, please notify the sender immediately by e-mail and delete the = message and any file attachments from your computer. Thank = you.

------=_NextPart_000_006B_01D5C9FD.831B4910-- From nobody Mon Jan 13 13:01:33 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43191208B9 for ; Mon, 13 Jan 2020 13:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2qjpsPJ3z7W for ; Mon, 13 Jan 2020 13:01:29 -0800 (PST) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22CF2120044 for ; Mon, 13 Jan 2020 13:01:29 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id b15so7988612lfc.4 for ; Mon, 13 Jan 2020 13:01:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZEmQV202EB0Qz6YvGqr1oGHnVMEUXpyVOValMajGUzk=; b=QCyKfs6gltD52b0arn9xABDTP88GJmilasYyjlvVeBDbnrPfnGb/dA1Ds4b7SIzNdZ 2pelpFponbMULxswC/8nEYqaFrIX+X12oy71sNjGlFtq5mRlDae9WF7PhH/qzVpRS4aY 1o2mx+ElN12GCuYFtnZNj4tNO/yu79X15azmEpsbq/9QHGDN4tOkeTcOKg2/9V3qVsiq lsmP6MbdvE2qJPKMCzH3pXvdQ0+/EQauJnjob6DRMrBTsLnNBmlImyhMzulZWnWP5IlG q8gj2VfquvhnBIvqu+U++yClFoZVvri/x2yLGxDKGv2HBpSqc/+NV1c1OWrhAdWnEMuR zxvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZEmQV202EB0Qz6YvGqr1oGHnVMEUXpyVOValMajGUzk=; b=auSMoK9SV4qFtdX5OZQDIUgb+G/DKDct98oHzY1F+J+ncW+azRFyI/sukAq4/S8GWU M+5gWOJLI926BedyB4tXXK9HyiRtlxaNxZ+zBnGHxdwrCkJD7o3fZsBkCWYb6c21VtZG nZ+C0OsA317N8070WsocKyOIL5tIF8IRt+FCzcsQKr8IKya3QlaYtk8/EOp0nBEOjZZb 7N3YEr0A/it7Pbye8Fc9Qlan0x0ddQJ8ov3Jpjfi8CeEpI6tgxNH75LCCi0o4QQnSOKn FbjWup09oIOsRLHBCtXuuj5XpUdLV9dLLulSwIVgmXmQoIdFEssQn8x6gCpFGBy6p9EQ DWig== X-Gm-Message-State: APjAAAUtYA8ldyIWDD1p+awN12btnSIo67HuLU6Eupb/Y8HuBzDOg+mi IjhfFkrq1grMOYJBUcxvQzSO/fznJx8A1I6TVGJePaYTNEQoQ3krlphdwtzbcdeJrBt4x/yu/JQ D0n1p1jEel8c= X-Google-Smtp-Source: APXvYqx98ItSK/VZOtIB6K+p+ehbmm27mbHyCtO3uYle1sX0z7lM8WlyYz5CdLca9eJCO5gbXrRxR7tEQAuLkIKIHE4= X-Received: by 2002:ac2:5f59:: with SMTP id 25mr8820289lfz.193.1578949287234; Mon, 13 Jan 2020 13:01:27 -0800 (PST) MIME-Version: 1.0 References: <9c32d171-9a4a-ba71-c989-92a177d9e989@gmx.de> <14a3c79d23e94d938be4a173a6c8256d@combitech.se> In-Reply-To: <14a3c79d23e94d938be4a173a6c8256d@combitech.se> From: Brian Campbell Date: Mon, 13 Jan 2020 14:01:00 -0700 Message-ID: To: Seitz Ludwig Cc: Ludwig Seitz , Roman Danyliw , "jwt-reg-review@ietf.org" , Jim Schaad , The IESG , "ace@ietf.org" , "drafts-lastcall@iana.org" , Benjamin Kaduk Content-Type: multipart/alternative; boundary="0000000000006260f1059c0bc7ec" Archived-At: Subject: Re: [Ace] [Jwt-reg-review] Requested review for IANA registration in draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2020 21:01:32 -0000 --0000000000006260f1059c0bc7ec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the updates Lugwig, Section 6.6. does propose one mitigation for the unbounded memory growth problem. However, it relies on the AS to do pretty specific things with the content of other claims for it to even be possible for an RS to perform the mitigation approach. Do you think, for interoperability, it needs to be more prescriptive? Like maybe requiring the cti/jti claim with specific content and characteristics when exi is present or embedding/encoding that sequence number in the value of the exi itself alongside the lifetime of the token. On Sat, Jan 11, 2020 at 9:16 AM Seitz Ludwig wrote: > Hello Brian, > > > > Thank you for this review! > > I have added text to clarify the formatting of these parameters and claim= s > when used in JSON-based interactions. > > More comments inline. > > > > Regards, > Ludwig > > > > *From:* Ace *On Behalf Of *Brian Campbell > *Sent:* den 10 januari 2020 21:57 > *To:* Ludwig Seitz > *Cc:* Roman Danyliw ; jwt-reg-review@ietf.org; Jim Schaad < > ietf@augustcellars.com>; The IESG ; ace@ietf.org; > drafts-lastcall@iana.org; Benjamin Kaduk > *Subject:* Re: [Ace] [Jwt-reg-review] Requested review for IANA > registration in draft-ietf-ace-oauth-authz > > > > I'm really struggling with understanding what the value of an > "ace_profile" claim actually would be in a JWT. A JSON string that's the > profile name (though 5.6.4.3 maybe prohibits > > that)? A JSON number that's an integer matching the CBOR Value? Somethin= g > else? > > > > [LS] For JSON the string representation is ok, I reworded 5.6.4.3 to > clarify this. > > > > Is the value of "exi" in a JWT a JSON number? Seems likely but it's > something that should probably be made explicit. > > > > [LS] Now explicit > > > > Also for "exi", the requirement in 5.8.3. to "keep track of the > identifiers of tokens containing the "exi" claim that have expired (in > order to avoid accepting them again)" seems problematic in that it sounds > like it's mandating an unbounded growth of memory use. > > > > Section 6.6. proposes a mitigation for the unbounded growth of memory use > problem. Does that resolve your reservations? > > > > The draft says that the "cnonce" claim (value) uses binary encoding. What > does that mean for JSON based JWT? > > > > [LS] Now Base64 encoded binary for JSON. > > > > On Sat, Dec 21, 2019 at 4:35 AM Ludwig Seitz wrote: > > Hello JWT registry reviewers, > > the IESG-designated experts for the JWT claims registry have asked me to > send a review request to you about the claims registered here: > > https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-29#section-8.12 > > Thank you in advance for you review comments. > > Regards, > > Ludwig > > _______________________________________________ > Jwt-reg-review mailing list > Jwt-reg-review@ietf.org > https://www.ietf.org/mailman/listinfo/jwt-reg-review > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000006260f1059c0bc7ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the updates Lugwig,

Section 6.6. does propose one mitigation for the unbounded memory growth= problem. However, it relies on the AS to do pretty specific things with th= e content of other claims for it to even be possible for an RS to perform t= he mitigation approach. Do you think, for interoperability, it needs to be = more prescriptive? Like maybe requiring the cti/jti claim with specific con= tent and characteristics when exi is present or embedding/encoding that seq= uence number in the value of the exi itself alongside the lifetime of the t= oken.


On Sat, Jan 11, 2020 at 9:16 AM Seitz Ludwig <= ;ludwig.seit= z@combitech.se> wrote:

Hello Brian,

=C2=A0

Thank you for this review!

I have added text to clarify the= formatting of these parameters and claims when used in JSON-based interact= ions.

More comments inline.<= /u>

=C2=A0

Regards,
Ludwig

=C2=A0

From: Ace <ace-bounces@ietf.org> On Behalf Of Brian Campbell
Sent: den 10 januari 2020 21:57
To: Ludwig Seitz <ludwig_seitz@gmx.de>
Cc: Roman Danyliw <rdd@cert.org>; jwt-reg-review@ietf.org; Jim Schaad <ietf@augustcellars.com>; Th= e IESG <iesg@ietf.org= >; ace@ietf.org; drafts-las= tcall@iana.org; Benjamin Kaduk <kaduk@mit.edu>
Subject: Re: [Ace] [Jwt-reg-review] Requested review for IANA regist= ration in draft-ietf-ace-oauth-authz

=C2=A0

I'm really struggling with understanding what th= e value of an "ace_profile" claim actually would be in a JWT. A J= SON string that's the profile name (though 5.6.4.3 maybe prohibits

that)?=C2=A0 A JSON number that's an integer mat= ching the CBOR Value? Something else?=C2=A0

=C2=A0

[LS] For JSON the string represe= ntation is ok, I reworded 5.6.4.3 to clarify this.

=C2=A0

Is the value of "exi" in a JWT a JSON numb= er? Seems likely but it's something that should probably be made explic= it.

=C2=A0

[LS] Now explicit<= /span>

=C2=A0

Also for "exi", the requirement in 5.8.3. = to "keep track of the identifiers of tokens containing the "exi&q= uot; claim that have expired (in order to avoid accepting them again)"= seems problematic in that it sounds like it's mandating an unbounded growth of memory use.

=C2=A0

Section 6.6. proposes a mitigati= on for the unbounded growth of memory use problem. Does that resolve your r= eservations?

=C2=A0

The draft says that the "cnonce" claim (va= lue) uses binary encoding. What does that mean for JSON based JWT?

=C2=A0

[LS] Now Base64 encoded binary f= or JSON.

=C2=A0


CONFIDENTI= ALITY NOTICE: This email may contain confidential and privileged material f= or the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibit= ed..=C2=A0 If you have received this communication in error, please notify = the sender immediately by e-mail and delete the message and any file attach= ments from your computer. Thank you.


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000006260f1059c0bc7ec-- From nobody Tue Jan 14 06:23:45 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11191200E9; Tue, 14 Jan 2020 06:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXs8HpXpKjiK; Tue, 14 Jan 2020 06:23:39 -0800 (PST) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2AF91200B4; Tue, 14 Jan 2020 06:23:38 -0800 (PST) Received: by mail-vs1-xe33.google.com with SMTP id t12so8294796vso.13; Tue, 14 Jan 2020 06:23:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Mdfzh5cOUiCLAQmPBJ7tEqS0VjPQLiDpeT6Kl/QXdXk=; b=j400oHefQgpj0dUhlFvbqJnWLhBtKwVmwjEtgFI4qxvHg4Yk4M6ld93hoPtrPNjtL1 DXwTZBuVUB+q1vcTiLatleBSm7bbrE0OUmoL8BmPeg+zT32+ldhvwxdhyXgFJnV58CLI 4Rali7gE9vwNt9WAksyzGAG3cB+qqRDKyZmT/gdwR9MY0UJ5ppg8jtaVbf9OvRcoqkdx lb12g4wjqFmfh9+7Z+uOcpySolN02Egzcv3J43sR2DwOPo82nspravmlLSaDmmDOGm6n OQ6uwUaxYFYJasso0Dzf7oxgXEECQzsI3ThvY8Y8qdVS+yTc60aXvyhOuqySthDpKauN sNQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Mdfzh5cOUiCLAQmPBJ7tEqS0VjPQLiDpeT6Kl/QXdXk=; b=d4kfWmIXQPa9F3H1e4vg81CH3ymZS1eOVNUciXzOZxpZuyqHmeKL26qxK1eVnmYe2K 7/zvcRjAowB0h5vIdEWN2FHww/3oQ7BBQwVyGwAO2TM7hXrkg/zcb0gyYlKBO7GXdy4+ Imc+XVQ4xfmC2AyUOSn1kcoE5xIIrl1NXnn98583FbiqkJwaiAdKRxSIZludR8IuHI6u KWJYskl5EDORHwFnZ2aQBEUoMXj+fkenMreNivVSs6MGBXiAzE6AItJVzBnTIUWCwW7X CkD13juHc430qL9uCougEyXD8dAqYXDe6K990fettBrHxt404ouYvdNMhznEgQgzY3M9 9C6A== X-Gm-Message-State: APjAAAXx6rykyDBzb9qZku6itMVEKGRJmaqxBdn2xZx0FwS9JDIWB+3I ciHlJwIzY0sNHUdTDatMaVVfb9EZwkb80iZr+/zdNjyk X-Google-Smtp-Source: APXvYqytngwfHfSv+yOMk44Jt6Ri/xRsHDijeRG149I9ky3e2Djqs01frFfbrHeq2L7fPSVx5kqdyGEcY6TMan1no6M= X-Received: by 2002:a67:fd63:: with SMTP id h3mr1592760vsa.221.1579011817605; Tue, 14 Jan 2020 06:23:37 -0800 (PST) MIME-Version: 1.0 References: <003f01d5c9b2$1fe439b0$5facad10$@augustcellars.com> In-Reply-To: <003f01d5c9b2$1fe439b0$5facad10$@augustcellars.com> From: Cigdem Sengul Date: Tue, 14 Jan 2020 14:23:35 +0000 Message-ID: To: Jim Schaad Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org, Ace Wg Content-Type: multipart/alternative; boundary="0000000000007c0edf059c1a56ed" Archived-At: Subject: Re: [Ace] draft-ietf-ace-mqtt-tls-profile - Validating a subscription is in scope X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2020 14:23:44 -0000 --0000000000007c0edf059c1a56ed Content-Type: text/plain; charset="UTF-8" Hello Jim, Topic filter and permission filter matching is something that I would like to have a better resolution as well. Responses inline. On Mon, Jan 13, 2020 at 1:38 AM Jim Schaad wrote: > I have run across an interesting question for doing validation of > subscriptions that I would like to get an opinion on. > > When doing a publish, there is not an issue. One simply takes the set of > values in the scope field as topic filters and checks the publication topic > against the set of permissible publication topic filters in the scope. [CS] Yes. > > When doing a subscribe, there are four distinct cases that can arise: > 1. The subscription is for a single topic and either is or is not > successfully matched against the scope topic filter. > [CS] Yes. > 2. The subscription is for a topic filter and it is identical to the scope > topic filter. > [CS] Yes. > 3. Both are topic filters and are not the same. Is one supposed to do > some > type of subset matching on the two filters or does one always say that this > is not a match. This is not addressed in the MQTT document and I am not > sure where it would be addressed. As an example: > > Scope value is subscribe_sport/# > Subscription topic is sport/tennis/# > > The second is clearly a subset of the first and thus it would seem logical > to include it, but it gets more complicated if one instead asks for > > Subscription topic is sport/+ > > In this case the two wild cards are not the same value. > We were thinking using a subset matching to check whether the token would permit the subscription request. For your example, a subscription request "sport/+" would cover all the single-levels under "sport" - including "sport/" but not "sport" . So if the scope is "subscribe_sport/#" which covers all multi-levels under "sport" (including "sport", the subscription request should still succeed. (i.e., the subscriber has a larger set of permissions than the request) Now when the broker receives a publication with "sport/tennis" then it should pass this message on to the subscriber. When it receives a publication "sport/tennis/player1" then it should not. This would be normal broker behaviour as well (without using ace). It gets interesting when the scope is more restricted than the subscription request. For instance, the scope is sport/+ But subscription is sport/# Should this be refused? Obviously the subscriber is attempting to subscribe to more than it has permission for. But does the broker still allow the subscription but reduce it to "sport/+"? Currently would opt for the former, because the second option may be hard to signal to the subscriber - the SUBACK reason string together with the user property field may be used for such feedback to the subscriber but would need to be defined properly. --Cigdem > > Jim > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --0000000000007c0edf059c1a56ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Jim,

Topic filter and permi= ssion filter matching is something that I would like to have a better resol= ution as well.=C2=A0
Responses inline.=C2=A0
On Mon, Jan 13, 2020 at 1:38 AM J= im Schaad <ietf@augustcellars.= com> wrote:
I have run across an interesting question for doing validation of
subscriptions that I would like to get an opinion on.

When doing a publish, there is not an issue.=C2=A0 One simply takes the set= of
values in the scope field as topic filters and checks the publication topic=
against the set of permissible publication topic filters in the scope.

[CS] Yes.=C2=A0
=C2=A0

When doing a subscribe, there are four distinct cases that can arise:
1.=C2=A0 The subscription is for a single topic and either is or is not
successfully matched against the scope topic filter.
<= br>
[CS] Yes.=C2=A0
=C2=A0
2.=C2=A0 The subscription is for a topic filter and it is identical to the = scope
topic filter.

[CS] Yes.=C2=A0
3.=C2=A0 Both are topic filters and are not the same.=C2=A0 Is one supposed= to do some
type of subset matching on the two filters or does one always say that this=
is not a match.=C2=A0 This is not addressed in the MQTT document and I am n= ot
sure where it would be addressed.=C2=A0 =C2=A0As an example:

Scope value is subscribe_sport/#
Subscription topic is sport/tennis/#

The second is clearly a subset of the first and thus it would seem logical<= br> to include it, but it gets more complicated if one instead asks for

Subscription topic is sport/+

In this case the two wild cards are not the same value.

We were thinking using a subset matching to check whether = the token would permit the subscription request.=C2=A0
For your e= xample, a subscription request=C2=A0
"sport/+" would co= ver all the single-levels under "sport" - including "sport/&= quot; but not "sport" .=C2=A0
So if the scope is "= subscribe_sport/#" which covers all multi-levels under "sport&quo= t; (including "sport", the subscription request should still succ= eed. (i.e., the subscriber has a larger set of permissions than the request= )

Now when the broker receives a publication with = "sport/tennis" then it should pass this message on to the subscri= ber.=C2=A0
When it receives a publication "sport/tennis/play= er1" then it should not. This would be normal broker behaviour as well= (without using ace).=C2=A0

It gets interesting wh= en the scope is more restricted than the subscription request.=C2=A0
<= div>For instance, the scope is sport/+
But subscription is sport/= #

Should this be refused? Obviously the subscriber= is attempting to subscribe to more than it has permission for. But does th= e broker still allow the subscription but reduce it to "sport/+"?=
Currently would opt for the former, because the second option ma= y be hard to signal to the subscriber - the SUBACK reason string together w= ith the user property field may be used for such feedback to the subscriber= but would need to be defined properly.

--Cigdem= =C2=A0

Jim


_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--0000000000007c0edf059c1a56ed-- From nobody Tue Jan 14 08:25:22 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8287F1208E8; Tue, 14 Jan 2020 08:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpqmiGtrFwvO; Tue, 14 Jan 2020 08:25:13 -0800 (PST) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 292481200B3; Tue, 14 Jan 2020 08:25:12 -0800 (PST) Received: by mail-vs1-xe2e.google.com with SMTP id n27so8595554vsa.0; Tue, 14 Jan 2020 08:25:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p7fwAJTABmgwMfmR+emRITRf+bM8Mt7V2MPe26CMaGA=; b=RvkLvoHrbY9OBmVhccIzYPYOyYUixv8HiJfprcuqbjhCvUDv8Vuiz0eLCdkC0CoOee fpSbiCJ/1xz+g58FpzYqGPtPY/j1duOAJxzQrEfhcgkjvdkhUwKc6i0uhyiWzHrojmVj FSuShipaH9mWItRRJ82CiPv8wybIUl7zXKZIUw6yVQP2JGQ8PIXBrWD9hbJuT/k/czRd 98JnQbZZzSzZWuQu93T2SCo3IiOt9zLaPlGCc7072wC/tKL63LeX9FJSzGa7kkr2GRda gH7W/xRi4N6/CnfTg/m/sw2I5lptm1dlE6Zksy49wU7JJed36bl/UMZK1aorM/E/bd+B agaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=p7fwAJTABmgwMfmR+emRITRf+bM8Mt7V2MPe26CMaGA=; b=hkOUPnECvrYXR77qGoeo0tYbVwFtDlocJC30T1KdZ/yhYiyZJLJSgYfgWphHiuEdoE lY3R8asMIbRGOk8uUhWH72PmHe8scGzr0c6PpCEOoHWICC/b960ADDfJDGVyHp5TGgzS OYVLYtdtIW3i11sp2Nhcbk9JvU1GrfATjdu67Ezn06OeegCee2nFzUPAM2tFY8752Lnm u88fOjckhL/LogyD5YB1EW4t3vAbhvZL2T18vluN+jkscOFKhWnB73gUxMxDJbq0smkS REYYa4NC8MsMNxPTV5tlR+scY0cjpx2FD/wj/DgNURzRawXz3L7ViiqB6Z4vCbmgph4j gQGw== X-Gm-Message-State: APjAAAVDVcf9RVnmlrXq84d6hXsfh8Q3fBrxzJfWNiHoP9ma8et0wOUJ AuPhmFD2+SgTRqg/EqWe2goFzAsPWsLzwmwcQnc= X-Google-Smtp-Source: APXvYqyuoKNQWTw5i3v+9gY9gMZzYmQtbjrhDPBjtz68UBMBiJnAa7AkiQv5WmDKxikkBTfI2hKpmvdwD3eLihvKdYI= X-Received: by 2002:a67:c798:: with SMTP id t24mr1796352vsk.62.1579019111030; Tue, 14 Jan 2020 08:25:11 -0800 (PST) MIME-Version: 1.0 References: <007401d5c0f3$6e80d320$4b827960$@augustcellars.com> In-Reply-To: <007401d5c0f3$6e80d320$4b827960$@augustcellars.com> From: Cigdem Sengul Date: Tue, 14 Jan 2020 16:25:08 +0000 Message-ID: To: Jim Schaad Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org, Ace Wg Content-Type: multipart/alternative; boundary="00000000000034eb2c059c1c09d5" Archived-At: Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-03 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2020 16:25:20 -0000 --00000000000034eb2c059c1c09d5 Content-Type: text/plain; charset="UTF-8" Thank you for this review, Jim. Responses inline. On Wed, Jan 1, 2020 at 10:33 PM Jim Schaad wrote: > > 2.2.2 - para 1, the last sentence seems to imply that the first connection > to publish to authz-info is not being done over a TLS connection. But the > sentence before that states that a TLS connection MUST be used for this. > Perhaps s/and is expected to try reconnecting over TLS./and reconnects, > potentially using client authentication with TLS./ > [CS] Yes, that part reads confusing. The aim was to say client authentication is not done over TLS, but connection can be over TLS. What it should be saying: Client can use either mqtt or mqtts to connect to the broker, but does only server validation, to push the token. After pushing the token, it is expected to do TLS:Known(RPK/PSK)-MQTT:none. (Although for PSK the token can be in psk_identity). Issue created: https://github.com/ace-wg/mqtt-tls-profile/issues/37 > 2.2.2 - I am unclear under what circumstances you could end put with a > token > which does not parse when processing a PUBLISH message. If the token > cannot > be parsed at connection time, that I can understand. However having parsed > the token then it does not make sense that the token becomes not parsable > at > the time of publishing. Am I missing something? > [CS] There is a misunderstanding. The PUBLISH message refers to the actual PUBLISH message to the "authz-info" topic which contains the token i.e., this may not parse to a token. (The PUBLISH message is not for other messages that are permissioned in the token.) The client connects (without much security), publishes the token to the public "authz-info" topic, which only the broker can read. Then, disconnects, and tries to connect with ace security. Since MQTT v5 can return error messages in response to PUBLISH messages, here, this is used to signal to the publisher that there is something wrong with its token. Added: https://github.com/ace-wg/mqtt-tls-profile/issues/38 > > 2.2.2 - The last paragraph is causing me confusion. Is this supposed to be > referencing the RS or the AS? If it is the AS, then I don't see how there > could be any confusion. Please expand this so it is clearer. > [CS] This is a typo - it should be RS. https://github.com/ace-wg/mqtt-tls-profile/issues/39 > 2.2.4 - I am having a problem with trying to parse the content of the AUTH > property. I have no problems with 2.2.4.3 because this is a zero length > sequence of bytes. However for 2.2.4.1 and 2.2.4.2 there is a token > (possibly binary with no length prefix) followed by an optional binary > cryptographic value. For introspection, I would need to figure out the > length of the token before I could make a guess at the length of the > cryptographic value. However given that there is no divider this does not > seem possible. This may also become a problem for the response from the > client in the event that there is a change from an 8-byte nonce to a > variable length one. > [CS] Not specified a format, because I thought we discarded the idea of using the variable-length nonce based on the meeting in Singapore. What would you suggest - introduce a specific format to accommodate variable length? length_of_token+binary data for token+(the rest is cryptographic value)? https://github.com/ace-wg/mqtt-tls-profile/issues/40 > 2.2.4.1 - In my view it is not the secret, but the content that is being > obtained from the TLS exporter. That is one is signing (or MACing) the > exporter value not using that value to compute a MAC on something else. > While it is true that only the two parties know that value, exposure to a > third party does not lead to a compromise. > [CS] I see - so reword "secret" to "content". Or do you have a suggestion for wording? https://github.com/ace-wg/mqtt-tls-profile/issues/41 > > 2.2.4.3 - I am not sure if the text is supposed to require an empty > authentication data field or to allow for the authentication data field to > be absent as well. > [CS] I checked whether it would be a protocol error to have only Authentication Method in MQTT, and it is not. Then it is best to omit authentication data field. Will correct the text that the document allows the CONNECT message to have an Authentication Method set to 'ace' and allows to omit the Authentication Data field. https://github.com/ace-wg/mqtt-tls-profile/issues/42 > > 3 - It might be worth while to put a pointer to section 4.7 of the MQTT V5 > spec here so that there is an indication of what the different wild card > characters do. I had to pop over there to make sure that I could figure it > out. > [CS] Will do. https://github.com/ace-wg/mqtt-tls-profile/issues/43 > 3.1 - Should you state that for a QoS of 0, the client should close the > connection w/ an '0x87' in the event of an authorization failure? I think > that this is supposed to happen but you have left it open. > [CS] Yes, I must have cut some text out. QoS of 0, the client is disconnected. Will add. https://github.com/ace-wg/mqtt-tls-profile/issues/44 > 6 - It is not clear to me if the authentication method described in this > section is permitted with MQTT v5 or not. It does not say, but it appears > to be a true statement. This should probably be explicit. > [CS] Yes, MQTT v5 broker can support this method as well - we say at the beginning something around backward compatibility to MQTT v3.1.1. Will make it more explicit. https://github.com/ace-wg/mqtt-tls-profile/issues/45 > > 2.2.4.3 - What is the name of the user property that is being returned > here? > > [CS] This is under-defined. It should say, the name pairs follow the same optional (name, value) parameters for AS request creation hints as defined in the core document. There could be multiple user properties in a CONNACK, one needs to make sure the size of the message does not grow beyond the Maximum Packet Size specified by the client. https://github.com/ace-wg/mqtt-tls-profile/issues/46 > > I am going to play with something else. I am sure I will find other issues > at a different time. > Thank you for your review. Much appreciated. --Cigdem > > Jim > > > > > > > > > > > > > > > Nits: > Section 2 Para 1 s/Broker.Figure 1/Broker. Figure 1/ > Section 2 Para 1 s/setup.The/setup. The/ > Section 2.2.2 Last Para s/when the AS/when the RS/ > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --00000000000034eb2c059c1c09d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Th= ank you for this review, Jim.=C2=A0
Responses inline.=C2=A0

On Wed, Jan 1, 2020 at 10:33 PM Jim Schaad <ietf@augustcellars.com> wrote:

2.2.2 - para 1, the last sentence seems to imply that the first connection<= br> to publish to authz-info is not being done over a TLS connection.=C2=A0 But= the
sentence before that states that a TLS connection MUST be used for this. Perhaps s/and is expected to try reconnecting over TLS./and reconnects,
potentially using client authentication with TLS./
[CS] Yes, that part reads confusing.=C2=A0
The aim wa= s to say client authentication is not done over TLS, but connection can be = over TLS.
What it should be saying:=C2=A0=C2=A0
Client = can use either mqtt or mqtts to connect to the broker, but does only server= validation, to push the token.=C2=A0
After pushing the token, it= is expected to do TLS:Known(RPK/PSK)-MQTT:none. (Although for PSK the toke= n can be in psk_identity).


2.2.2 - I am unclear under what circumstances you could end put with a toke= n
which does not parse when processing a PUBLISH message.=C2=A0 If the token = cannot
be parsed at connection time, that I can understand.=C2=A0 However having p= arsed
the token then it does not make sense that the token becomes not parsable a= t
the time of publishing.=C2=A0 Am I missing something?
=
[CS] There is a misunderstanding. The PUBLISH message refers= to the actual PUBLISH message to the "authz-info" topic which co= ntains the token i.e., this may not parse to a token. (The PUBLISH message = is not for other messages that are permissioned in the token.)
Th= e client connects (without much security), publishes the token to the publi= c "authz-info" topic, which only the broker can read.=C2=A0
=
Then, disconnects, and tries to connect with ace security.=C2=A0
=

Since MQTT v5 can return error messages in response to = PUBLISH messages, here, this is used to signal to the publisher that there = is something wrong with its token.=C2=A0

=C2=A0

2.2.2 - The last paragraph is causing me confusion.=C2=A0 Is this supposed = to be
referencing the RS or the AS?=C2=A0 If it is the AS, then I don't see h= ow there
could be any confusion.=C2=A0 Please expand this so it is clearer.

[CS] This is a typo - it should be RS.=C2=A0

=

2.2.4 - I am having a problem with trying to parse the content of the AUTH<= br> property.=C2=A0 I have no problems with 2.2.4.3 because this is a zero leng= th
sequence of bytes.=C2=A0 However for 2.2.4.1 and 2.2.4.2 there is a token (possibly binary with no length prefix) followed by an optional binary
cryptographic value.=C2=A0 For introspection, I would need to figure out th= e
length of the token before I could make a guess at the length of the
cryptographic value.=C2=A0 However given that there is no divider this does= not
seem possible.=C2=A0 This may also become a problem for the response from t= he
client in the event that there is a change from an 8-byte nonce to a
variable length one.

[CS] Not specified= a=C2=A0 format, because I=C2=A0 thought we discarded the idea of using the= variable-length nonce based on the meeting in Singapore.=C2=A0
W= hat would you suggest - introduce a specific format to accommodate variable= length?
length_of_token+binary data for token+(the rest is crypt= ographic value)?


2.2.4.1 - In my view it is not the secret, but the content that is being obtained from the TLS exporter.=C2=A0 That is one is signing (or MACing) th= e
exporter value not using that value to compute a MAC on something else.
While it is true that only the two parties know that value, exposure to a third party does not lead to a compromise.

<= div>[CS] I see - so reword "secret" to "content".
=
Or do you have a suggestion for wording?=C2=A0 =C2=A0

2.2.4.3 - I am not sure if the text is supposed to require an empty
authentication data field or to allow for the authentication data field to<= br> be absent as well.

[CS] I checked wheth= er it would be a protocol error to have only Authentication Method in MQTT,= and it is not.
Then it is best to omit authentication data field= .=C2=A0
Will correct the text that the document allows the CONNEC= T message to have an Authentication Method set to 'ace' and allows = to omit the Authentication Data field.=C2=A0
=C2=A0

3 - It might be worth while to put a pointer to section 4.7 of the MQTT V5<= br> spec here so that there is an indication of what the different wild card characters do.=C2=A0 I had to pop over there to make sure that I could figu= re it
out.

[CS] Will do.=C2=A0


3.1 - Should you state that for a QoS of 0, the client should close the
connection w/ an '0x87' in the event of an authorization failure?= =C2=A0 I think
that this is supposed to happen but you have left it open.
=
=C2=A0
[CS]=C2=A0
Yes, I must have cut some text o= ut. QoS of 0, the client is disconnected.=C2=A0 Will add.=C2=A0
<= a href=3D"https://github.com/ace-wg/mqtt-tls-profile/issues/44">https://git= hub.com/ace-wg/mqtt-tls-profile/issues/44=C2=A0=C2=A0

6 - It is not clear to me if the authentication method described in this section is permitted with MQTT v5 or not.=C2=A0 It does not say, but it app= ears
to be a true statement.=C2=A0 This should probably be explicit.

[CS] Yes,=C2=A0
MQTT v5 broker can suppo= rt this method as well - we say at the beginning something around backward = compatibility to MQTT v3.1.1.
Will make it more explicit.=C2=A0
h= ttps://github.com/ace-wg/mqtt-tls-profile/issues/45=C2=A0=C2=A0

=C2=A0

2.2.4.3 - What is the name of the user property that is being returned here= ?

[CS]
This is under-defined. It should say, = the name pairs follow the same optional (name, value) parameters for AS req= uest creation hints as defined in the core document. There could be multipl= e user properties in a CONNACK, one needs to make sure the size of the mess= age does not grow beyond the Maximum Packet Size specified by the client.= =C2=A0
=

I am going to play with something else.=C2=A0 I am sure I will find other i= ssues
at a different time.

Thank you for your= review. Much appreciated.=C2=A0
--Cigdem=C2=A0
=C2=A0<= /div>

Jim














Nits:
Section 2 Para 1 s/Broker.Figure 1/Broker.=C2=A0 Figure 1/
Section 2 Para 1=C2=A0 s/setup.The/setup.=C2=A0 The/
Section 2.2.2 Last Para s/when the AS/when the RS/


_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--00000000000034eb2c059c1c09d5-- From nobody Tue Jan 14 08:50:23 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF90120A12; Tue, 14 Jan 2020 08:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5LQJTshqp1c; Tue, 14 Jan 2020 08:50:17 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FFCC120A10; Tue, 14 Jan 2020 08:50:16 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 14 Jan 2020 08:50:07 -0800 From: Jim Schaad To: 'Cigdem Sengul' CC: , 'Ace Wg' References: <003f01d5c9b2$1fe439b0$5facad10$@augustcellars.com> In-Reply-To: Date: Tue, 14 Jan 2020 08:50:05 -0800 Message-ID: <00de01d5cafa$adefb420$09cf1c60$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DF_01D5CAB7.9FCF5A50" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQG68Cx4Lv4gMYGrZ81gKRTlPGEQPwK+Nj7oqAoi4lA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] draft-ietf-ace-mqtt-tls-profile - Validating a subscription is in scope X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2020 16:50:22 -0000 ------=_NextPart_000_00DF_01D5CAB7.9FCF5A50 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Cigdem Sengul =20 Sent: Tuesday, January 14, 2020 6:24 AM To: Jim Schaad Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org; Ace Wg Subject: Re: [Ace] draft-ietf-ace-mqtt-tls-profile - Validating a = subscription is in scope =20 Hello Jim, =20 Topic filter and permission filter matching is something that I would = like to have a better resolution as well.=20 Responses inline.=20 On Mon, Jan 13, 2020 at 1:38 AM Jim Schaad > wrote: I have run across an interesting question for doing validation of subscriptions that I would like to get an opinion on. When doing a publish, there is not an issue. One simply takes the set = of values in the scope field as topic filters and checks the publication = topic against the set of permissible publication topic filters in the scope. =20 [CS] Yes.=20 =20 When doing a subscribe, there are four distinct cases that can arise: 1. The subscription is for a single topic and either is or is not successfully matched against the scope topic filter. =20 [CS] Yes.=20 =20 2. The subscription is for a topic filter and it is identical to the = scope topic filter. =20 [CS] Yes.=20 3. Both are topic filters and are not the same. Is one supposed to do = some type of subset matching on the two filters or does one always say that = this is not a match. This is not addressed in the MQTT document and I am not sure where it would be addressed. As an example: Scope value is subscribe_sport/# Subscription topic is sport/tennis/# The second is clearly a subset of the first and thus it would seem = logical to include it, but it gets more complicated if one instead asks for Subscription topic is sport/+ In this case the two wild cards are not the same value. =20 We were thinking using a subset matching to check whether the token = would permit the subscription request.=20 For your example, a subscription request=20 "sport/+" would cover all the single-levels under "sport" - including = "sport/" but not "sport" .=20 So if the scope is "subscribe_sport/#" which covers all multi-levels = under "sport" (including "sport", the subscription request should still = succeed. (i.e., the subscriber has a larger set of permissions than the = request) =20 Now when the broker receives a publication with "sport/tennis" then it = should pass this message on to the subscriber.=20 When it receives a publication "sport/tennis/player1" then it should = not. This would be normal broker behaviour as well (without using ace).=20 =20 [JLS] This is what I expected the answer to be, I will need to figure = out what this algorithm looks like now for all of the corner cases. =20 It gets interesting when the scope is more restricted than the = subscription request.=20 For instance, the scope is sport/+ But subscription is sport/# =20 Should this be refused? Obviously the subscriber is attempting to = subscribe to more than it has permission for. But does the broker still = allow the subscription but reduce it to "sport/+"? Currently would opt for the former, because the second option may be = hard to signal to the subscriber - the SUBACK reason string together = with the user property field may be used for such feedback to the = subscriber but would need to be defined properly. =20 [JLS] Given that this is not defined in the base MQTT specification, = most clients would not expect this if the ACE is grafted on the side of = the program. I would therefore say this is a =E2=80=9Cnot = authorized=E2=80=9D and go on. =20 Jim =20 =20 --Cigdem=20 Jim _______________________________________________ Ace mailing list Ace@ietf.org =20 https://www.ietf.org/mailman/listinfo/ace ------=_NextPart_000_00DF_01D5CAB7.9FCF5A50 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: = Cigdem Sengul <cigdem.sengul@gmail.com>
Sent: Tuesday, = January 14, 2020 6:24 AM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: = draft-ietf-ace-mqtt-tls-profile@ietf.org; Ace Wg = <ace@ietf.org>
Subject: Re: [Ace] = draft-ietf-ace-mqtt-tls-profile - Validating a subscription is in = scope

 

Hello Jim,

 

Topic = filter and permission filter matching is something that I would like to = have a better resolution as well. 

Responses inline. 

On Mon, Jan 13, 2020 at 1:38 AM Jim Schaad <ietf@augustcellars.com> = wrote:

I have = run across an interesting question for doing validation = of
subscriptions that I would like to get an opinion on.

When = doing a publish, there is not an issue.  One simply takes the set = of
values in the scope field as topic filters and checks the = publication topic
against the set of permissible publication topic = filters in the scope.

 

[CS] Yes. 

 


When = doing a subscribe, there are four distinct cases that can = arise:
1.  The subscription is for a single topic and either is = or is not
successfully matched against the scope topic = filter.

 

[CS] Yes. 

 

2.  = The subscription is for a topic filter and it is identical to the = scope
topic filter.

 

[CS] Yes. 

3.  = Both are topic filters and are not the same.  Is one supposed to do = some
type of subset matching on the two filters or does one always = say that this
is not a match.  This is not addressed in the MQTT = document and I am not
sure where it would be addressed.  =  As an example:

Scope value is = subscribe_sport/#
Subscription topic is sport/tennis/#

The = second is clearly a subset of the first and thus it would seem = logical
to include it, but it gets more complicated if one instead = asks for

Subscription topic is sport/+

In this case the = two wild cards are not the same = value.

 

We were thinking using a subset matching to check = whether the token would permit the subscription = request. 

For your = example, a subscription request 

"sport/+" would cover all the single-levels = under "sport" - including "sport/" but not = "sport" . 

So if the scope is "subscribe_sport/#" which = covers all multi-levels under "sport" (including = "sport", the subscription request should still succeed. (i.e., = the subscriber has a larger set of permissions than the = request)

 

Now when the broker receives a publication with = "sport/tennis" then it should pass this message on to the = subscriber. 

When it = receives a publication "sport/tennis/player1" then it should = not. This would be normal broker behaviour as well (without using = ace). 

 

[JLS] This is what I expected the answer to be, I will = need to figure out what this algorithm looks like now for all of the = corner cases.

 

It gets interesting when the scope is more restricted = than the subscription request. 

For instance, the scope is = sport/+

But subscription = is sport/#

 

Should this be refused? Obviously the subscriber is = attempting to subscribe to more than it has permission for. But does the = broker still allow the subscription but reduce it to = "sport/+"?

Currently would opt for the former, because the second = option may be hard to signal to the subscriber - the SUBACK reason = string together with the user property field may be used for such = feedback to the subscriber but would need to be defined = properly.

 

[JLS] Given that this is not defined in the base MQTT = specification, most clients would not expect this if the ACE is grafted = on the side of the program.=C2=A0 I would therefore say this is a = =E2=80=9Cnot authorized=E2=80=9D and go on.

 

Jim

 

 

--Cigdem 


Jim


____________________________________= ___________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

------=_NextPart_000_00DF_01D5CAB7.9FCF5A50-- From nobody Wed Jan 15 04:44:44 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5561200A3; Wed, 15 Jan 2020 04:44:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpIsvzO-t2bI; Wed, 15 Jan 2020 04:44:37 -0800 (PST) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B43A120119; Wed, 15 Jan 2020 04:44:37 -0800 (PST) Received: by mail-ua1-x92c.google.com with SMTP id z24so6165551uam.7; Wed, 15 Jan 2020 04:44:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qdBVrtOF2pVEXnLs4SLLk3kGAuEeMxY/7s3ixXrPtq0=; b=MrxFfc5kXemBThA2WY8qJpDIlSm/vGjcRUvfDGX79RPPPI4psijrIpCirdWbzxihVE K+U1jAp2ZAM1FuQCJLlIh2rG8qwd1KR8CRzBYw86P2TQN00QeQVl7vbWptU+n788eX2J 4jtROVzxYGIuQTNqeKzJjSTsWOZmFeExLX1GHgb6WFpXfdfnt5TxdpuTNOpgFIlRBjNy 0KKF0wkpzxrc0+RrgYYh/Igbu2oUQGmpM4pTfKoXY+XfqP3IsAKdkoRxqei57xYV225C doNB6UdFmxrRHhBgCDhpMfyQfUD98vGj4gg/khn5LWJK4mXRQMh7RfakJ6eIRERkbt5V bqNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qdBVrtOF2pVEXnLs4SLLk3kGAuEeMxY/7s3ixXrPtq0=; b=MWzWQ0bfe6smzoTzxV0T1Ew9ks5t4I1ihpGZYw8q/rmAfBC/fC+Kxnf/D6hk1+tCtL 6LLwH4A/Od0QaflLROuvhFDqBClp3DElTDxyJfHOntGQg5TOvp6CyBKgHFAUmza5o1EM h17A5QKEMjJFi09+odcghVJMBPYIwpjo18Jidq25VBlOhgWvi27AKs7hC8RtT/GWeE30 ZgnJKcyKqnjaOho4nGW3QCNKv7BRCdpzGboLAdpaB4Tpckr49M2EiqXluM4Tbx1KGqPt aBQZBdyU648iJLOysjyJgL80L+M/wdpLVQ25cvWv5hxYNmwEVil2TfebIcuCVm7G4eLk wKXw== X-Gm-Message-State: APjAAAXDI5Ow8fJmVz9zfpWbaOtUjNriQBh8N/ZU9IU9+MhuQiMiwgdZ Jx23wABmdDmiTm1Q2PWLGsj3pbyGe52OlKJppZV3Akwx5K8= X-Google-Smtp-Source: APXvYqwuROIRQj/R6vo7Kx3+yIC/4DnEv1HbiCop1B9B8mKz8lmWTNyiwtKjEgg0lrPCmkkQL2K652TsAhrkr5m13tA= X-Received: by 2002:ab0:2ea6:: with SMTP id y6mr14024702uay.25.1579092276330; Wed, 15 Jan 2020 04:44:36 -0800 (PST) MIME-Version: 1.0 References: <003f01d5c9b2$1fe439b0$5facad10$@augustcellars.com> <00de01d5cafa$adefb420$09cf1c60$@augustcellars.com> In-Reply-To: <00de01d5cafa$adefb420$09cf1c60$@augustcellars.com> From: Cigdem Sengul Date: Wed, 15 Jan 2020 12:44:25 +0000 Message-ID: To: Jim Schaad Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org, Ace Wg Content-Type: multipart/alternative; boundary="00000000000032c35f059c2d12fd" Archived-At: Subject: Re: [Ace] draft-ietf-ace-mqtt-tls-profile - Validating a subscription is in scope X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2020 12:44:43 -0000 --00000000000032c35f059c2d12fd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, It gets interesting when the scope is more restricted than the subscription request. For instance, the scope is sport/+ But subscription is sport/# Should this be refused? Obviously the subscriber is attempting to subscribe to more than it has permission for. But does the broker still allow the subscription but reduce it to "sport/+"? > > > [JLS] Given that this is not defined in the base MQTT specification, most > clients would not expect this if the ACE is grafted on the side of the > program. I would therefore say this is a =E2=80=9Cnot authorized=E2=80= =9D and go on. > > > [CS] Agreed. Another issue that we should say something about is the case when multiple permission strings aggregated together gives enough permission to the subscription request, based on the _current_ topic hierarchy. Example: Scope strings in the token were: publish_sport/tennis publish_sport/basketball and then the client asks for publish_sport/+ If tennis and basketball are the only topics under sport, then this is a valid request. But, if the topic hierarchy is changes during the connection time (adds sport/baseball) then subscriber gets PUBLISH messages for something they should not. When topic subscriptions are not protected, the broker would send anything at the single level for sport/+ and would not worry about the new additions after the subscription. When topic subscriptions are protected, the Broker can choose to do two things: 1) Allow the subscription but internally subscribe the clients to sport/basketball and sport/tennis only. or 2) Reject the subscription and the client needs to ask for subscriptions that are a subset or equal to their permission strings. So the client specifically needs to ask for publish_sport/tennis and publish_sport/basketball matching its scope strings. But then scope parameter cannot be optional and must be included in the AS response. or 3) Allow the subscription, when a new level is added, check the permissions of all active subscribers, send DISCONNECT if the current permissions do not apply to the new hierarchy. 1 would need to be again signalled to the client, 2 might be too restrictive, and 3 may introduce a processing load if things are changing all the time (which I do not expect). Leaning towards 3... Any thoughts? --Cigdem > Jim > > > > > > --Cigdem > > > Jim > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > --00000000000032c35f059c2d12fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,


It gets interesting when the scope is more res= tricted than the subscription request.=C2=A0

For instance, the scope i= s sport/+

But subscription is sport/#

=C2=A0

Should this be refused? Obviousl= y the subscriber is attempting to subscribe to more than it has permission = for. But does the broker still allow the subscription but reduce it to &quo= t;sport/+"?=C2=A0

=C2=A0

[JLS] Given that this is not defined in the base MQTT specificat= ion, most clients would not expect this if the ACE is grafted on the side o= f the program.=C2=A0 I would therefore say this is a =E2=80=9Cnot authorize= d=E2=80=9D and go on.

=C2=A0=


[CS] Agreed. Another= issue that we should say something about is the case when multiple permiss= ion strings aggregated together gives enough permission to the subscription= request, based on the _current_ topic hierarchy.=C2=A0
Example:<= /div>
Scope strings in the token were: publish_sport/tennis=C2=A0 publi= sh_sport/basketball
and then the client asks for publish_sport/+<= /div>

If tennis and basketball are the only topics under= sport, then this is a valid request.=C2=A0
But, if the topic hie= rarchy is changes during the connection time (adds sport/baseball) then sub= scriber gets PUBLISH messages for something they should not.=C2=A0
When topic subscriptions are not protected, the broker would send an= ything at the single level for sport/+ and would not worry about the new ad= ditions after the subscription.=C2=A0

=
When topic subscriptions are protected, the Broker can choose to do tw= o things:
1) Allow the subscription but internally subscribe the = clients to sport/basketball and sport/tennis only.
or
2= ) Reject the subscription and the client needs to ask for subscriptions tha= t are a subset or equal to their permission strings. So the client specific= ally needs to ask for publish_sport/tennis and publish_sport/basketball mat= ching its scope strings. But then scope parameter cannot be optional and mu= st be included in the AS response.=C2=A0
or
3) Allow th= e subscription, when a new level is added, check the permissions of all act= ive subscribers, send DISCONNECT if the current permissions do not apply to= the new hierarchy.=C2=A0

1 would need to be again= signalled to the client, 2 might be too restrictive, and 3 may introduce a= processing load if things are changing all the time (which I do not expect= ).=C2=A0
Leaning towards 3...=C2=A0 Any thoughts?

--Cigdem



<= /div>

=C2=A0

J= im

=C2=A0

=C2=A0

--Cigdem=C2=A0


Jim


______________________________________= _________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

--00000000000032c35f059c2d12fd-- From nobody Wed Jan 15 05:48:19 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2709A12003E; Wed, 15 Jan 2020 05:47:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <157909607587.4688.921630484532292273@ietfa.amsl.com> Date: Wed, 15 Jan 2020 05:47:56 -0800 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-key-groupcomm-04.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2020 13:47:56 -0000 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 : Key Provisioning for Group Communication using ACE Authors : Francesca Palombini Marco Tiloca Filename : draft-ietf-ace-key-groupcomm-04.txt Pages : 46 Date : 2020-01-15 Abstract: This document defines message formats and procedures for requesting and distributing group keying material using the ACE framework, to protect communications between group members. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-04 https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-key-groupcomm-04 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/ From nobody Wed Jan 15 06:13:31 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E187C120071; Wed, 15 Jan 2020 06:13:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <157909759288.4630.9573114747883778438@ietfa.amsl.com> Date: Wed, 15 Jan 2020 06:13:12 -0800 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-key-groupcomm-oscore-04.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2020 14:13:13 -0000 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 : Key Management for OSCORE Groups in ACE Authors : Marco Tiloca Jiye Park Francesca Palombini Filename : draft-ietf-ace-key-groupcomm-oscore-04.txt Pages : 32 Date : 2020-01-15 Abstract: This specification defines an application profile of the ACE framework for Authentication and Authorization, to request and provision keying material in group communication scenarios that are based on CoAP and secured with Group Object Security for Constrained RESTful Environments (OSCORE). This application profile delegates the authentication and authorization of Clients that join an OSCORE group through a Resource Server acting as Group Manager for that group. This application profile leverages protocol-specific transport profiles of ACE to achieve communication security, server authentication 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-key-groupcomm-oscore/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-04 https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-oscore-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-key-groupcomm-oscore-04 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/ From nobody Wed Jan 15 07:16:49 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE801200D8 for ; Wed, 15 Jan 2020 07:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.759 X-Spam-Level: X-Spam-Status: No, score=-1.759 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SBL=0.141, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lx0ztnTS3bdf for ; Wed, 15 Jan 2020 07:16:01 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140052.outbound.protection.outlook.com [40.107.14.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 226AC120090 for ; Wed, 15 Jan 2020 07:16:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dSo/viLaAXTK0VJ71+zlk47Ajh3LyBOJD8F360SskCFYGszBYcYZLkw4W4pmiXuijivj4Q5fyZMx5tOF+K0f5sLW5+02Cm1+HdAwAJ58OjDHeTxZVS5xYtWUIsYseRj5fRdJcvfej5XXryIYiqUPxNp9T6A3O4gWuDcR9zSfWtvA3qCFA8lgLOgOKohtGtrAEyR0qnb8mlsTquipOpcVAnQnQnWChHqQeCfICheJ4tpqaxcouukJ+BhP0vQlO8hr/h69gx2Mn6LONDJ0s4JKA+Kqb+UMQhmlmjIUey3qiVuNmSwwQ4ExBy50MMYLrYgRlZsVBJOIl4AMhvM8dVN3zw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YDl+8SJDB7TtRf0BVlO6JpefxKUtflGgFlyYvmFV0N0=; b=OkFzCMSzraSBvNfqUHAXzbcA7KUsKT8jzGG6UUI4wMhcMsy3OcQhvrd1Zs2nDBDeoweeKL6w5KReFZiaFOBDobYMbgiYWxgjif2VTDYvydVkkRqjlZXRl6nr4zXItOt0VnNjay5JOYSznFfXXY1zLCn5tnKYkTIH16dCmOPjCabetXHu4GauyO/SCP8I+M9UHg6r0i1Ss9wJboAVTVsuHokgl73qBrGHzyVJvG3JQh+My6cBPxp8vygIe10Z7q+AovZGtUt+0KGimiphw08n8YHHMdBhs2z6qysQPrawjwHW2k9Y2guQP95hIgV4TwZ/jGm3x9Zs4Yrx7mp2HJlqhg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YDl+8SJDB7TtRf0BVlO6JpefxKUtflGgFlyYvmFV0N0=; b=MTIGlV/p/ZYligYuOKhlyInlaNGUquPhmDZ5Fct9iyoa4OUS/7n/UhRHYroieaKdyO9Gc2timz2AQIbIAu1cQCphqVGkEjUH7Y/xYNU7YNqMx2wysGR9TiRhoFTRkq1W33Tcud6j63TWY6ImwCSp9CPdfHkslPNIeIizafyOSb4= Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (10.165.195.159) by VI1P189MB0320.EURP189.PROD.OUTLOOK.COM (10.165.194.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.10; Wed, 15 Jan 2020 15:15:58 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::3485:ce83:891b:469]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::3485:ce83:891b:469%4]) with mapi id 15.20.2623.017; Wed, 15 Jan 2020 15:15:58 +0000 Received: from [10.8.8.24] (196.196.244.5) by HE1PR09CA0077.eurprd09.prod.outlook.com (2603:10a6:7:3d::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.10 via Frontend Transport; Wed, 15 Jan 2020 15:15:58 +0000 From: Marco Tiloca To: "consultancy@vanderstok.org" , Ace Thread-Topic: [Ace] ace-key-groupcomm-oscore-03 Thread-Index: AQHVnrmD5xGCEIkuiUOCZsC5NBu0nafsL+WA Date: Wed, 15 Jan 2020 15:15:58 +0000 Message-ID: <79596b2e-a911-e51f-ea28-f6d0eba54723@ri.se> References: <4ac02bb82ae9a67ad93c4ffe34063f19@bbhmail.nl> In-Reply-To: <4ac02bb82ae9a67ad93c4ffe34063f19@bbhmail.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-clientproxiedby: HE1PR09CA0077.eurprd09.prod.outlook.com (2603:10a6:7:3d::21) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) authentication-results: spf=none (sender IP is ) smtp.mailfrom=marco.tiloca@ri.se; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [196.196.244.5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7aa22d31-4a63-4924-b48d-08d799cdd2fd x-ms-traffictypediagnostic: VI1P189MB0320: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(366004)(346002)(136003)(396003)(39860400002)(189003)(199004)(4001150100001)(2616005)(66946007)(64756008)(66616009)(6486002)(956004)(66446008)(36756003)(5001810100001)(66556008)(66476007)(2906002)(53546011)(110136005)(66574012)(52116002)(186003)(16526019)(5660300002)(316002)(16576012)(26005)(478600001)(71200400001)(81156014)(8676002)(966005)(31696002)(86362001)(81166006)(31686004)(8936002)(44832011); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P189MB0320; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ri.se does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Z/klx3Kskgddrq6ivi29G1b2bbo0y7YpFjlDeGGLkDjoiHVnNEmn9vUFVYz8bGhwEOvJo4fSCVtlkyBXaU2ee+lk9XTi8sndMENm1y9qEzyenc5rBynClKPq7PwJymCheR9xmwHVPKuFkL9+WbTQR2BmIQ9Mrcf+zkIJlolk6tfhW4FHjnkHt/O16jmumT6CMTrECU6YYeqbpRaiVvU7vogehwjbH7S3tvRRuMK7gRQf4/UUDiiWVcOjWCIsxS9QYG8MnYv9khDcyIVy7Zu7vb33HF9APeTeACeY2LalC5Lon49onJXMAZK+yPiVhJF7KuLM1PV7oYm4OVSzDmRka/AerSfQv7Oh6w+duCLUcTnWTQcLpZbveUaIwiFLQg7hzrLDoOjJs048NS05Vij21TCTOUVXx9UAoIMu/t+BBJJpsTyu2nFpVL3vZmZvocTUTKotS1rY007kCDtPw68vsH3VmA+XJVZvfgywo1G7vgE= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ArcZnRWZ8sQysgT5jG13s79jmxt5rJMqc" MIME-Version: 1.0 X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 7aa22d31-4a63-4924-b48d-08d799cdd2fd X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2020 15:15:58.4781 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NkMtEtJ3t4KV5PKHfVY9J+l/foSFJf2EwD5EHi+xEafA+uTx0ZWkQEPa/CaerIcwa32Mcbfqcq1zwa23ttIDVQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0320 Archived-At: Subject: Re: [Ace] ace-key-groupcomm-oscore-03 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2020 15:16:06 -0000 --ArcZnRWZ8sQysgT5jG13s79jmxt5rJMqc Content-Type: multipart/mixed; boundary="pB5r6BfspwTB0xcbzljY8Qpx11kzCRD8v" --pB5r6BfspwTB0xcbzljY8Qpx11kzCRD8v Content-Type: multipart/alternative; boundary="------------41DE9A587126B0B07B0BD173" Content-Language: en-US This is a multi-part message in MIME format. --------------41DE9A587126B0B07B0BD173 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Peter, Thank you for your comments! We have addressed them in the latest version -04 : https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-04 Please, see some more details in line below. Best, /Marco On 2019-11-19 10:12, Peter van der Stok wrote: > Hi Authors, > > Having read the document and comparing it with ace-key-groupcomm, I > have to agree with Jim that this document repeats in "other" words the > same subjects as specified in ace-key-groupcomm. > In this form, it is very difficult to find out the differences between > the two documents. > We shortened this document, to avoid repetitions and rather have simple pointers to ace-key-groupcomm , where especially general content not strictly related to the Group OSCORE case has been moved to. > It would be good if the same terminology was used or their equivalence > was pointed out: > eg: Client vs joining node Section 2 now clarifies that the joining node is the Client of ace-key-groupcomm. > Group-manager versus KDC Section 2 now clarifies that the Group Manager is the KDC of ace-key-groupcomm, as a Resource Server. > joining request versus joining authorization "Joining authorization" is not used anymore. After Section 4.1 "Token POST", authorization aspects such validation of requests against a stored Access Token are referred as in ace-key-groupco= mm > > Secondly, I suggest to make this draft much shorter, and mostly refer > to the sections of ace-key-groupcomm and point out the differences. In > many cases a list of items that MUST be present, are optional or not > present at all will suffice.=C2=A0 > For example such an enumeration is done under the bullet key on page 15= =2E > We have tried to keep only the details and deltas from ace-key-groupcomm , and increased the usage of bullet lists. > New parameters can receive more text as is done for cs_alg, cs_params, > cs_key_params, and cs_key_enc. > Done, in Section 4.4. > Hope this helps, It does, as always. Thanks! > Thanks for all your work, > greetings, > > Peter > --=20 > > Peter van der Stok > vanderstok consultancy > mailto: consultancy@vanderstok.org > , stokcons@bbhmail.nl > > www: www.vanderstok.org > tel NL: +31(0)492474673 =C2=A0=C2=A0=C2=A0=C2=A0F: +33(0)966015248 > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --------------41DE9A587126B0B07B0BD173 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Peter,

Thank you for your comments! We have addressed them in the latest version -04 :

https://tools.ietf.org/html/dra= ft-ietf-ace-key-groupcomm-oscore-04

Please, see some more details in line below.

Best,
/Marco

On 2019-11-19 10:12, Peter van der Sto= k wrote:
Hi Authors,

Having read the document and comparing it with ace-key-groupcomm, I have to agree with Jim that this document repeats in "other" words the same subjects as specified in ace-key-groupcomm.
In this form, it is very difficult to find out the differences between the two documents.


<MT>
We shortened this document, to avoid repetitions and rather have simple pointers to ace-key-groupcomm , where especially general content not strictly related to the Group OSCORE case has been moved to.
</MT>

It would b= e good if the same terminology was used or their equivalence was pointed out:
eg: Client vs joining node

<MT>
Section 2 now clarifies that the joining node is the Client of ace-key-groupcomm.
</MT>

Group-mana= ger versus KDC

<MT>
Section 2 now clarifies that the Group Manager is the KDC of ace-key-groupcomm, as a Resource Server.
</MT>

joining request versus joining authorization

<MT>
"Joining authorization" is not used anymore.

After Section 4.1 "Token POST", authorization aspects such validation of requests against a stored Access Token are referred as in ace-key-groupcomm
</MT>

Secondly, I suggest to make this draft much shorter, and mostly refer to the sections of ace-key-groupcomm and point out the differences. In many cases a list of items that MUST be present, are optional or not present at all will suffice.=C2=A0
For example such an enumeration is done under the bullet key on page 15.


<MT>
We have tried to keep only the details and deltas from ace-key-groupcomm , and increased the usage of bullet lists.
<MT>

New parameters can receive more text as is done for cs_alg, cs_params, cs_key_params, and cs_key_enc.


<MT>
Done, in Section 4.4.
</MT>


Hope this helps,

<MT>
It does, as always. Thanks!
</MT>

Thanks for= all your work,
greetings,

Peter
--

Peter van der Stok
vanderstok consultancy
mailto: consultancy@vanderstok.org, = stokcons@bbhmail.nl
www: www.vand= erstok.org
tel NL: +31(0)492474673 =C2=A0=C2=A0=C2=A0=C2=A0F: +33(0)966015= 248

____________________________=
___________________
Ace mailing list
Ace@ie=
tf.org
https://www.ietf.org/mailman/listinfo/ace


--=20
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistag=C3=A5ngen 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501
https://www=
=2Eri.se
--------------41DE9A587126B0B07B0BD173-- --pB5r6BfspwTB0xcbzljY8Qpx11kzCRD8v-- --ArcZnRWZ8sQysgT5jG13s79jmxt5rJMqc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl4fLKcACgkQ7iZktA5Y 2kPOJgf+KdgVRmxiUmPDj8defVA9XIxajiEVkteDV06VsiZ3fgk2KXK5DMM6FpqT JOxEmlvJhP8+nuacuG07wtQENTSwc6yYq8rbqNEXV5SEpA5QnYX/eZs0BP54XnW+ O3Dj9JALJSzISO5DZ4WUSdIwDVlALMw0FUP4zHRmZFOMIpVy2T14AL7K78IqIgCn WGOEHxQlvBfXJv8FchsJuELzfZ9WsI2IYhzmthWTiV9c2y/inpsSlVJtWo+AbztR SKRFZhFIIk9SnIW2OS+BkTaPJe6CBAANzTXod+VQTBTwo55WskoDyX1QRcaP6K9F j/oucRwuC7RbWAGW/jt+q82bHIc15g== =Bl0R -----END PGP SIGNATURE----- --ArcZnRWZ8sQysgT5jG13s79jmxt5rJMqc-- From nobody Wed Jan 15 09:21:51 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C630F120885; Wed, 15 Jan 2020 09:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SBL=0.141, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTd_eGX7d300; Wed, 15 Jan 2020 09:21:07 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30040.outbound.protection.outlook.com [40.107.3.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46D871208A9; Wed, 15 Jan 2020 09:21:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MM2ixrlbpgH3rWMEt+ZN5BCXnPkqoySIpUdvZ7foASvwICvbWYHMGYx/Pt0Rz31lTXmkBhfh02AD36tFVfnIwW+/KPk/nhSjkfn7j5yWlB/N2XhOOmktbh6M7GyRp6IbfBuOCh8qSArmib3OfZ1NCPQEw+hICkWHFrfxXGy8L8PcB68xCynSkxaQm2RKmucGOqJgDuoEzzAHDQMofOXFMm27fZk+vrV8KFzgCqQaheFYKkTvDQa8JIk/tELIynnE9O+UrqmMpF+cCW/zOAYpYl8Obnr0etaGdnUu+pTpaWMKyKJWzkJLgppZszjug/u9nX3/cJjJooYC1qtVN2ihbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=90xPxXPr+MoxJIFYvQeIKDRR/m2mbnOwHUGOicrehjs=; b=X9SRaaUS/xGqLL32m/kFCO8bDjyJg5USJdw5zS3tbLG7Rpbgm2xmyfUdl5s6YsPyNa3VLwqgAWrP5Wx+kfpO8EfUL05S8oI33pVGhq1OMCUOP/2m6MyD5NB4zhX76BJgibWKD/itXtZJqCxCdGioZbe23VByQu9omFz0VDdbX+W9huIFM8fYd56s5MDK6u+K4fKhUubNgqyeyqttnkJhvGIkxuzTBfqE7uUs+VzKGK/3CsbHCM0jLyWhAlfBYkf5Pwpcr5O1GnDelX8/0zNThvkIN+7ewrEUcwEujZIw1oJILAtAGlfW//Mup1/5L6P/fJ+b/6+b9mi2quwL2zgNOg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=90xPxXPr+MoxJIFYvQeIKDRR/m2mbnOwHUGOicrehjs=; b=JQTR/syY6A4wHLKeU4AT3c3zPNI4OxGdek3d4ssR90TOt3yk86X8aNTo5iwzROk932WXHbAlKsbslZ/UFhT1GsHnbY9olz4C9TLj9pRFoIOd9tHv4n1/1YGyyAEgUeQcUqghANmHVOKCsa+85KBEqkflGXZKoj2D9XaJoEw3ymI= Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (10.165.195.159) by VI1P189MB0478.EURP189.PROD.OUTLOOK.COM (10.165.189.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.10; Wed, 15 Jan 2020 17:21:04 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::3485:ce83:891b:469]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::3485:ce83:891b:469%4]) with mapi id 15.20.2623.017; Wed, 15 Jan 2020 17:21:03 +0000 Received: from [10.8.8.24] (196.196.244.5) by HE1PR1001CA0002.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:3:f7::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.20 via Frontend Transport; Wed, 15 Jan 2020 17:21:03 +0000 From: Marco Tiloca To: Jim Schaad , "draft-tiloca-ace-oscore-gm-admin@ietf.org" CC: "ace@ietf.org" Thread-Topic: [Ace] remarks on draft-tiloca-ace-oscore-gm-admin-00 Thread-Index: AdWfJkCd54YEkIoYSoqR2Q9ieECPkwnF3wsAAKzrB4AAta7/gA== Date: Wed, 15 Jan 2020 17:21:03 +0000 Message-ID: References: <01b401d59f2e$ff406560$fdc13020$@augustcellars.com> <000001d5c8f1$6b0c7630$41256290$@augustcellars.com> In-Reply-To: <000001d5c8f1$6b0c7630$41256290$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-clientproxiedby: HE1PR1001CA0002.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:3:f7::12) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) authentication-results: spf=none (sender IP is ) smtp.mailfrom=marco.tiloca@ri.se; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [196.196.244.5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cd6e3252-b632-41b1-fc56-08d799df4c67 x-ms-traffictypediagnostic: VI1P189MB0478: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:983; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(136003)(376002)(396003)(346002)(189003)(199004)(26005)(186003)(44832011)(31686004)(956004)(66574012)(81156014)(16526019)(66556008)(2616005)(31696002)(66616009)(66476007)(30864003)(5660300002)(81166006)(64756008)(66446008)(71200400001)(8936002)(4001150100001)(16576012)(5001810100001)(478600001)(110136005)(316002)(4326008)(52116002)(8676002)(966005)(66946007)(53546011)(6486002)(86362001)(36756003)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P189MB0478; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ri.se does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WBKbnpPI4Tv2Fp3ve8Ndsc374+Ec1B4gXmEO/S4TvqJASvlu2fZhcQNcEUo9tKhACwScxByNcVV+ItmRH2YyTDg5fbSgduiaLqs1stxpNBwdeXo7YKZyxcRayl1tes7OuPZON6HnmAU2Fb8lhmoo0JEe4im0RK0VGqCQJCjV6YLfN+0alh06WYiBSOBeeuquhbnNgQlujWOrBAmfrGr1WXCzMXa5c0VGFPZHJF1oANjvZmsGUHHTC66BRNuNydRuSP6PcinDKM42+RiXztYYOj60FE+kMcBd9ury5IPoZ3cSMdlr4VeJnhoPxggkSmwvn2t6s5FavT7LmDgE6R3TK5wwP/SykKEZcV6g54x1gdS5Xzdb/jxyvDX8uSH8bEBPDa4mjeHugcy5skyLMl3N2smg07NISeDwIyTJltD5lRBsCzYx1lIzni6WiBZfYZc+BIZ5nOE+qkctIQAkvomwuCGLRgPgVhSe5e0/afihe9M= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MHeBmcVC2eiWX5u4bAeVeuMUrwcYk9OmA" MIME-Version: 1.0 X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: cd6e3252-b632-41b1-fc56-08d799df4c67 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2020 17:21:03.7942 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1kwpYFpJEXRxZ1DXmihCeGuUFyvYuL2JOZmDL5A1+owoijkhCQ+8ALhgLua4D9Yx0wGsABJQwdDw0BJPK8X8nA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0478 Archived-At: Subject: Re: [Ace] remarks on draft-tiloca-ace-oscore-gm-admin-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2020 17:21:12 -0000 --MHeBmcVC2eiWX5u4bAeVeuMUrwcYk9OmA Content-Type: multipart/mixed; boundary="LS82kBmskolMStvuPrX6lJqo45T1GHOlo" --LS82kBmskolMStvuPrX6lJqo45T1GHOlo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Jim, Thanks for your reply, see more comments inline. Best, /Marco On 2020-01-12 03:38, Jim Schaad wrote: > > -----Original Message----- > From: Ace On Behalf Of Marco Tiloca > Sent: Wednesday, January 8, 2020 8:08 AM > To: Jim Schaad ; draft-tiloca-ace-oscore-gm-adm= in@ietf.org > Cc: ace@ietf.org > Subject: Re: [Ace] remarks on draft-tiloca-ace-oscore-gm-admin-00 > > Hi Jim, > > Thanks a lot for this review! > > We have been working on an updated version accessible at [1], which is = already taking into account your comments on CoRAL. > > Please, find below inline some more replies and open points. > > Best, > /Marco > > [1] > https://gitlab.com/crimson84/draft-tiloca-ace-oscore-gm-admin/blob/v-01= /draft-tiloca-ace-oscore-gm-admin.md > > On 2019-11-20 00:13, Jim Schaad wrote: >> This is just going to be a high level review on how things are done=20 >> rather than a detailed review on each line of text. >> >> 1. - Go and read that CoRE Pub-Sub update document - you know the one = >> that Klaus and friends have not managed to get written since the model= =20 >> proposal was done way back when. > > Yes, we are now relying on an akin interface, along the lines of the no= w published draft https://datatracker.ietf.org/doc/draft-hartke-t2trg-cor= al-pubsub/ > > >> 2. Re-write this to use CoRAL - Yes I know that this makes another=20 >> dependency on getting it published from the CoRE group, but I don't=20 >> want to do things multiple times. > > We have now also added examples in CoRAL, for all the interactions betw= een Administrator and Group Manager, now also extended with FETCH for fil= tered retrieval. > > >> 3. I think that this document really needs to be able to be used with= >> HTTP/JSON as well as CoAP. If you can get the JSON version of CoRAL = from >> Klaus then this falls out without any work. > > We are now saying the CoRAL examples are in text format, but they are i= n CBOR or JSON on the wire, with no particular additional effort. Is this= enough? > > > Sounds good. > >> 4. Are you making it a requirement that the group name be the same as= =20 >> the group identifier assigned by the "group_name" parameter? If so=20 >> then having some type of title and description would seem to be almost= mandatory. > > They are in fact the very same thing. The "group_name" parameter specif= ies the group name, as intended to identify the OSCORE group both by the = administrator and the joining nodes in the other related documents. We ca= n use only "invariant name" rather than "invariant identifier". Are we mi= ssing something? If so, what do you suggest we should give a title and de= scription to? > > > If you are looking at "group_name":"GP00123", then as a configuration a= gent it is difficult to know just what this group is supposed to be. In = this case some type of title or description helps to figure that out. We can add a new group configuration parameter 'group_title', as a CBOR text string. This specifies a human-readable descriptive name of the group, suggesting what it is about. > >> 5. There needs to be some parameters around pointing to the correct=20 >> AS and so forth. The management API may reject because it does not tr= ust the AS. >> Don't assume that this is a single value for the AS either. > > This is good and also aligned with other related drafts. > > If we interpret your suggestion correctly: > > 1) The POST request to /manage may specify also an optional 'as_uri' > parameter, with the link to a suggested AS. The GM may accept the sugge= stion or not. If not, it has to think of an alternative AS, as valid issu= er of tokens for joining that group. > > 2) The GM must have one more parameter in the group configuration with = the effective AS URI, i.e. either one provided by the administrator and a= ccepted, or one otherwise decided. > > Do you think of any additional related parameters to be included in the= POST request, other than 'as_uri'? Perhaps the public key of the suggest= ed AS if applicable? > > Do you think the suggestion in the request should actually be a list of= AS, out of which the GM may pick up at most one? > > > I have put something into draft-schaad-core-reef which starts thinking = about this. I think that we need to sit down and do a brainstorming sess= ion to figure out what items should/should not be put into such a structu= re. > With pleasure, and thanks for the pointer :-) Out of my hat, I can think of: the URI of one AS and its /token endpoint; the profile(s) that the Group Manager have to use (if it supports them) for letting joining nodes enter the group; the public key of the AS if applicable; the ACE audience that the Group Manager has to use for this group. >> 6. You are missing a lot of management detail on the POST to the=20 >> group node. Some of the things that are missing would be: >> a) Is the group active or inactive > > We can have one more parameter on the group-configuration resource for = this. > > We are interpreting active/inactive as follows. Ideally, upon creating = the group, the request can specify the initial status as active or inacti= ve. Upon later updating the group by sending a request to the group-confi= guration resource, the administrator can change the status (or read it th= rough a GET). > > Then the active/inactive status has two parallel scopes: > > 1) one scope is for the GM alone, i.e the GM would allow the joining of= new group members only if the group is set as active. > > 2) when the group is set as inactive, the current group members should = refrain from sending and should not expect receiving any message protecte= d with that group key material. However, there is no way to actually forc= e them to. > > In support to scope (2), when the status changes to inactive, the GM sh= ould inform group members about that. To this end, the group-membership r= esource intended for group members would also include a parameter reflect= ing the group status and aligned in value with the one in the group-confi= guration resource. Then, there are two ways to inform the group members o= f a status change. > > a) A way is to have the group members observing the group-membership re= source (that they may have been doing already anyway for notification-bas= ed rekeying). > > b) A second way is for the group members to have a dedicated local reso= urces for this (and other) kind of control communication (e.g. > rekeying). This is something we are also considering in > ace-key-groupcomm(-oscore) for receiving individual rekeying messages. > In either case this would require either: i) each node to provide the G= M with the URI to such local resource, in the join request; or ii) the GM= to include in the join response to each joining node a same multicast ad= dress targeting a local resource that that node has to create to receive = control messages. > > > I don't remember for sure what I was thinking about when I wrote this. = I think that I was more interested in if one can or cannot join a group = when it is inactive and what happens. If you set a group to inactive, ar= e all members of the group removed or does the group just stop issuing ne= w keys? Building on the previous reply, an inactive group would mean that: i) no new members are admitted, thus no new keys to new members; ii) stop issuing new keys for current members; iii) current members are expected to stop communicating (which should rely on informing them) but are not removed. So the group is temporarily inactive but still exists. > >> b) How does the server react if you change a the content encryption=20 >> algorithm, is this a simple re-key operation or is it more complicated= > > An easy answer would be rekeying the group, just as for any other trigg= ering reason. I agree this should be mention in this draft. > > However, I think a more elaborated description of what happens if the a= lgorithm is changed (regardless why and how) should be actually better gi= ven in oscore-groupcomm (the what) and in ace-key-groupcomm-oscore (the h= ow). > > > Punting to a different document is fine as long as it really is there. = However, this is the place where it appears to be changed by an external= source and thus seems to be a good place to talk about it. Agree, this document is in fact acting as a use case of its own for this.= >> c) How does the server react if you change the signature algorithm? =20 >> This would seem to be a much harder thing to do if the group is not=20 >> empty or not active as everybody is going to need to re-join. > > Right. If the signature algorithm changes, the current public keys may = be not compatible with it any longer. We see the following possible ways,= assuming the current group members have learnt of the new algorithm in u= se. > > 1) The hard way, i.e. everyone leaving and re-joining. > > 2) A more lightweight way, i.e. relying on yet another operation for cu= rrent group members on the GM, to upload a new public key consistent with= the new algorithm. This would require to proof possession of the corresp= onding private key, as it is done upon joining. Probably, in this case, t= his can happen like we do in the Group OSCORE profile of ACE between the = Client and the AS, see the bullet point on 'client_cred_verify' at [2]. > > And again it looks like details on the way this is done fits better in = other documents. > > [2] > https://tools.ietf.org/html/draft-tiloca-ace-group-oscore-profile-01#se= ction-3.1 > > > > See comment above. As above, yes, something should be said here. Formally, the extended keying material is distributed as in a rekeying, but the only difference would be the signature algorithm. This is enough for the group members to understand what happens and what to do. If they leave and fully join again, it's just about following the same procedure of ietf-ace-key-groupcomm oscore. The alternative (2) above would require one more functionality exported by the Group Manager for current group members to upload a new and compatible public key (and this has to be followed by proof-of-possession). This may be achieved with a new PUT handler to the group-membership resource group-oscore/GROUPNAME/pub-key (see https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-04#sectio= n-8 ) > >> d) Other parameter that are changed may be just as bad as changing the= =20 >> signature algorithm - how the re-key is done jumps immediately to mind= =2E > > Yes, changing HKDF/Alg results in what discussed two replies above; cha= nging anything else (thus related to signatures) results in what discusse= d in the reply above. > > > Much of this may go to say that changing this parameters kicks everybod= y off the group and restarts from scratch. It seems better to leave the burden of a clear decision to the Administrator. That is, if the Administrator has good reasons to update those parameters, even though a rekeying will follow, so be it. Or, the Administrator can delete the group altogether and create it again, if believed to be better. On the other hand, it sounds better to avoid that the Group Manager itself decides to delete a group. > >> 7. Is there currently any way for a KDC to signal to all of the=20 >> members that have joined that the key group no longer exists? A=20 >> DELETE would seem to indicate the need to be able to do this. > > Right, the DELETE of a group-configuration resource would trigger somet= hing like this. The current resource maintaining on the GM consists > in: destroying both group-configuration and group-membership resource, = then reply to the Administrator. > > That said, a possible extension to also inform current group members is= akin to what we describe above about signaling that the group has moved = to inactive state. That is: > > i) if group members observe the group-membership resource, a 4.04 notif= ication is sent to them, upon deleting that resource. > > ii) if group members have their own local resource to receive control m= essages from the GM, a control message can inform about the deletion of s= uch group-membership resource. This would be particularly convenient to b= e sent over multicast. This method (ii) would actually require the GM to = send these messages to the group members first, and only afterwards actua= lly delete the group-membership resource, in case information such as the= destination addresses and URIs to consider are stored as part of the gro= up-membership resource itself. > > A group member can of course discover what happened at any time, just b= y sending any type of request to the deleted group-membership resource an= d getting a 4.04 response back. > > The actual difference between an existing inactive group and a deleted = group is that the latter has no way back, and would need to be re-created= from scratch on the GM by the Administrator. > > > Also could say that you can only delete a successfully inactivated grou= p. Ok, this has two consequences: 1) We can add one more group-configuration boolean parameter 'active', that the Administrator also controls. 2) Before issuing a DELETE to delete a group, the Administrator has to change 'active' to FALSE, and get a confirmation response from the Group Manager. However, I wonder what you mean with "successfully". What can make the Group Manager fail/hold from changing 'active' from TRUE to FALSE when requested to do so by the Administrator? > > Jim > > >> Jim >> >> >> > -- > Marco Tiloca > Ph.D., Senior Researcher > > RISE Research Institutes of Sweden > Division ICT > Isafjordsgatan 22 / Kistag=C3=A5ngen 16 > SE-164 40 Kista (Sweden) > > Phone: +46 (0)70 60 46 501 > https://www.ri.se > > > --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --LS82kBmskolMStvuPrX6lJqo45T1GHOlo-- --MHeBmcVC2eiWX5u4bAeVeuMUrwcYk9OmA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl4fSfcACgkQ7iZktA5Y 2kNTjgf/UmIKEHQWT1HbkyjbGdQlkpVCsMym9MUAcUzHAbw26zN57tgAFLvx5997 LfbS6USulNRBrpQ/B+NVWA61TEEWGZFKFTtmnyCtXldyyIaxCH6elQqoEBfoo7A2 M7zcTjcp28ohmOLNST77b7An1/2lxYfL73OYhdt2iGr1jroylVq+1c82ElrlLT8b Q54RacuDBHG6VPCgkJbZlEGXVsNE6BSwp1YAJyG0r2dco7L7wzdKpKSZTuZDAaAl 00Rg+jrMSleJS8m/g0zcsWogi9wyH8pgdVXlYC5MEeLMzdeFcXJW+/uGNJa48nyO oPvK4WLtjFAkb9tVLUdmHXefHcyRUA== =3rGy -----END PGP SIGNATURE----- --MHeBmcVC2eiWX5u4bAeVeuMUrwcYk9OmA-- From nobody Wed Jan 15 11:37:14 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7331209AF for ; Wed, 15 Jan 2020 11:37:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWRBhKENuvBV for ; Wed, 15 Jan 2020 11:37:06 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A47581209B5 for ; Wed, 15 Jan 2020 11:37:03 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00FJax3u024913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 15 Jan 2020 14:37:01 -0500 Date: Wed, 15 Jan 2020 11:36:59 -0800 From: Benjamin Kaduk To: ace@ietf.org Message-ID: <20200115193659.GK30105@kduck.mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: [Ace] Fwd: [OAUTH-WG] Doodle Poll for scheduling a discussion on proof-of-possession tokens X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2020 19:37:13 -0000 Hi all, The OAuth WG is planning to talk about proof-of-possession tokens; it would be great if some of the ACE WG participants could contribute with our experiences so far. -Ben On Mon, Jan 13, 2020 at 05:18:57PM +0000, Hannes Tschofenig wrote: > Hi all, > > at the Singapore IETF meeting we talked about setting time aside for discussing proof-of-possession tokens. > > To schedule a call we put a Doodle poll together: > https://doodle.com/poll/sqhbeeg6knp435ag > > Please let us know by the end of the week what dates work for you. > > Ciao > Hannes & Rifaat > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Jan 16 06:54:37 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E47512008A; Thu, 16 Jan 2020 06:54:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , ace-chairs@ietf.org, ietf@augustcellars.com, Jim Schaad , kaduk@mit.edu, ace@ietf.org, draft-ietf-ace-coap-est@ietf.org, rfc-editor@rfc-editor.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <157918647644.26135.10968277659832656121.idtracker@ietfa.amsl.com> Date: Thu, 16 Jan 2020 06:54:36 -0800 Archived-At: Subject: [Ace] Protocol Action: 'EST over secure CoAP (EST-coaps)' to Proposed Standard (draft-ietf-ace-coap-est-18.txt) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 14:54:37 -0000 The IESG has approved the following document: - 'EST over secure CoAP (EST-coaps)' (draft-ietf-ace-coap-est-18.txt) as Proposed Standard This document is the product of the Authentication and Authorization for Constrained Environments Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ Technical Summary Enrollment over Secure Transport [RFC 7030] provides a REST style interface for doing X.509 certificate enrollment as well as other operations to support the enrollments. This document provides a set of procedures to run this REST API using DTLS and CoAP rather than TLS and HTTP. Working Group Summary Following adoption of the document progress in the WG was smooth. The major issues in terms of formating and structure were worked out prior to WG adoption. Document Quality The document has been reviewed and is directly build on RFC 7030. Prior to the document going into last call three different groups of implementers got together and had a series of virtual inter-op events. These lead to several changes and clarifications in the document as problems were identified. The document mirrors EST in using the tls-unique value for channel binding, even though it is now preferred to use TLS exporters instead of tls-unique. The intent is that CoAP-EST will gain support for TLS exporters when it is defined for traditional EST, and that the ACE WG is not the correct place to do that work. Personnel The Document Shepherd is Jim Schaad. The responsible Area Director is Benjamin Kaduk From nobody Fri Jan 17 18:40:39 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57CF8120086; Fri, 17 Jan 2020 18:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hlt30HYcWox; Fri, 17 Jan 2020 18:40:36 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DB64120041; Fri, 17 Jan 2020 18:40:35 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 17 Jan 2020 18:40:29 -0800 From: Jim Schaad To: 'Cigdem Sengul' CC: , 'Ace Wg' References: <007401d5c0f3$6e80d320$4b827960$@augustcellars.com> In-Reply-To: Date: Fri, 17 Jan 2020 18:40:26 -0800 Message-ID: <012301d5cda8$a5c74f00$f155ed00$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0124_01D5CD65.97A595A0" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQGeWvSvz9UOHo3iGPAvq1BxgK1ERAHRc1DkqFANpiA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-03 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 02:40:38 -0000 ------=_NextPart_000_0124_01D5CD65.97A595A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Cigdem Sengul =20 Sent: Tuesday, January 14, 2020 8:25 AM To: Jim Schaad Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org; Ace Wg Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-03 =20 Thank you for this review, Jim.=20 Responses inline.=20 =20 On Wed, Jan 1, 2020 at 10:33 PM Jim Schaad > wrote: 2.2.2 - I am unclear under what circumstances you could end put with a = token which does not parse when processing a PUBLISH message. If the token = cannot be parsed at connection time, that I can understand. However having = parsed the token then it does not make sense that the token becomes not = parsable at the time of publishing. Am I missing something? =20 [CS] There is a misunderstanding. The PUBLISH message refers to the = actual PUBLISH message to the "authz-info" topic which contains the = token i.e., this may not parse to a token. (The PUBLISH message is not = for other messages that are permissioned in the token.) The client connects (without much security), publishes the token to the = public "authz-info" topic, which only the broker can read.=20 Then, disconnects, and tries to connect with ace security.=20 =20 Since MQTT v5 can return error messages in response to PUBLISH messages, = here, this is used to signal to the publisher that there is something = wrong with its token.=20 =20 Added: https://github.com/ace-wg/mqtt-tls-profile/issues/38 =20 [JLS] Ok =E2=80=93 I see where I got mixed in in reading this. I think = this may just be a problem on my end and you might not be able to do = this better. =20 =20 =20 2.2.4 - I am having a problem with trying to parse the content of the = AUTH property. I have no problems with 2.2.4.3 because this is a zero length sequence of bytes. However for 2.2.4.1 and 2.2.4.2 there is a token (possibly binary with no length prefix) followed by an optional binary cryptographic value. For introspection, I would need to figure out the length of the token before I could make a guess at the length of the cryptographic value. However given that there is no divider this does = not seem possible. This may also become a problem for the response from the client in the event that there is a change from an 8-byte nonce to a variable length one. =20 [CS] Not specified a format, because I thought we discarded the idea = of using the variable-length nonce based on the meeting in Singapore.=20 What would you suggest - introduce a specific format to accommodate = variable length? length_of_token+binary data for token+(the rest is cryptographic value)? https://github.com/ace-wg/mqtt-tls-profile/issues/40 =20 [JLS] I put in a comment on the github issue about what I was looking = for. Additionally, my only possible problem with the fixed size nonce = is that the IESG or Security Directorate down the line may decide that = it is too small for some reason (16 bytes signed by a 521-bit (65+ byte = key)). Some might consider it to be small for a SHA-256 MAC operation. = Not the exact same situation here for TLS as it is not really a compact = protocol. But it may considered to be for the IoT variants being used. = I don=E2=80=99t know. =20 =20 Jim =20 I am going to play with something else. I am sure I will find other = issues at a different time. =20 Thank you for your review. Much appreciated.=20 --Cigdem=20 =20 Jim Nits: Section 2 Para 1 s/Broker.Figure 1/Broker. Figure 1/ Section 2 Para 1 s/setup.The/setup. The/ Section 2.2.2 Last Para s/when the AS/when the RS/ _______________________________________________ Ace mailing list Ace@ietf.org =20 https://www.ietf.org/mailman/listinfo/ace ------=_NextPart_000_0124_01D5CD65.97A595A0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: = Cigdem Sengul <cigdem.sengul@gmail.com>
Sent: Tuesday, = January 14, 2020 8:25 AM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: = draft-ietf-ace-mqtt-tls-profile@ietf.org; Ace Wg = <ace@ietf.org>
Subject: Re: [Ace] Review of = draft-ietf-ace-mqtt-tls-profile-03

 

Thank you for this review, = Jim. 

Responses = inline. 

 

On = Wed, Jan 1, 2020 at 10:33 PM Jim Schaad <ietf@augustcellars.com> = wrote:




2.2.2 - I am unclear under what circumstances you = could end put with a token
which does not parse when processing a = PUBLISH message.  If the token cannot
be parsed at connection = time, that I can understand.  However having parsed
the token = then it does not make sense that the token becomes not parsable = at
the time of publishing.  Am I missing = something?

 

[CS] There is a misunderstanding. The PUBLISH message = refers to the actual PUBLISH message to the "authz-info" topic = which contains the token i.e., this may not parse to a token. (The = PUBLISH message is not for other messages that are permissioned in the = token.)

The client = connects (without much security), publishes the token to the public = "authz-info" topic, which only the broker can = read. 

Then, = disconnects, and tries to connect with ace = security. 

 

Since MQTT v5 can return error messages in response to = PUBLISH messages, here, this is used to signal to the publisher that = there is something wrong with its = token. 

 

Added: https://git= hub.com/ace-wg/mqtt-tls-profile/issues/38

 

[JLS] Ok = =E2=80=93 I see where I got mixed in in reading this.=C2=A0 I think this = may just be a problem on my end and you might not be able to do this = better.

 

 

 


2.2.4 = - I am having a problem with trying to parse the content of the = AUTH
property.  I have no problems with 2.2.4.3 because this is = a zero length
sequence of bytes.  However for 2.2.4.1 and = 2.2.4.2 there is a token
(possibly binary with no length prefix) = followed by an optional binary
cryptographic value.  For = introspection, I would need to figure out the
length of the token = before I could make a guess at the length of the
cryptographic = value.  However given that there is no divider this does = not
seem possible.  This may also become a problem for the = response from the
client in the event that there is a change from an = 8-byte nonce to a
variable length = one.

 

[CS] Not specified a  format, because I  = thought we discarded the idea of using the variable-length nonce based = on the meeting in Singapore. 

What would you suggest - introduce a specific format = to accommodate variable length?

length_of_token+binary data for token+(the rest is = cryptographic value)?

 https://git= hub.com/ace-wg/mqtt-tls-profile/issues/40

 

[JLS] I put = in a comment on the github issue about what I was looking for.=C2=A0 = Additionally,=C2=A0 my only possible problem with the fixed size nonce = is that the IESG or Security Directorate down the line may decide that = it is too small for some reason (16 bytes signed by a 521-bit (65+ byte = key)).=C2=A0 Some might consider it to be small for a SHA-256 MAC = operation.=C2=A0 Not the exact same situation here for TLS as it is not = really a compact protocol.=C2=A0 But it may considered to be for the IoT = variants being used.=C2=A0 I don=E2=80=99t = know.

 

 

Jim

 


I am = going to play with something else.  I am sure I will find other = issues
at a different time.

 

Thank you for your review. Much = appreciated. 

--Cigdem 

 


Jim











=


Nits:
Section 2 Para 1 s/Broker.Figure 1/Broker.  = Figure 1/
Section 2 Para 1  s/setup.The/setup.  = The/
Section 2.2.2 Last Para s/when the AS/when the = RS/


_______________________________________________
Ace = mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

------=_NextPart_000_0124_01D5CD65.97A595A0-- From nobody Fri Jan 17 19:28:42 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEBD012004A; Fri, 17 Jan 2020 19:28:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id al11QMneotWf; Fri, 17 Jan 2020 19:28:36 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13C0F120041; Fri, 17 Jan 2020 19:28:36 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 17 Jan 2020 19:28:29 -0800 From: Jim Schaad To: 'Cigdem Sengul' CC: , 'Ace Wg' References: <003f01d5c9b2$1fe439b0$5facad10$@augustcellars.com> <00de01d5cafa$adefb420$09cf1c60$@augustcellars.com> In-Reply-To: Date: Fri, 17 Jan 2020 19:28:27 -0800 Message-ID: <012a01d5cdaf$5aad85f0$100891d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_012B_01D5CD6C.4C8D0510" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQG68Cx4Lv4gMYGrZ81gKRTlPGEQPwK+Nj7oAjfsVBYCZEJuyafqneGA X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] draft-ietf-ace-mqtt-tls-profile - Validating a subscription is in scope X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 03:28:39 -0000 ------=_NextPart_000_012B_01D5CD6C.4C8D0510 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Cigdem Sengul =20 Sent: Wednesday, January 15, 2020 4:44 AM To: Jim Schaad Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org; Ace Wg Subject: Re: [Ace] draft-ietf-ace-mqtt-tls-profile - Validating a = subscription is in scope =20 Hello, =20 It gets interesting when the scope is more restricted than the = subscription request.=20 For instance, the scope is sport/+ But subscription is sport/# =20 Should this be refused? Obviously the subscriber is attempting to = subscribe to more than it has permission for. But does the broker still = allow the subscription but reduce it to "sport/+"?=20 =20 [JLS] Given that this is not defined in the base MQTT specification, = most clients would not expect this if the ACE is grafted on the side of = the program. I would therefore say this is a =E2=80=9Cnot = authorized=E2=80=9D and go on. =20 =20 [CS] Agreed. Another issue that we should say something about is the = case when multiple permission strings aggregated together gives enough = permission to the subscription request, based on the _current_ topic = hierarchy.=20 Example: Scope strings in the token were: publish_sport/tennis = publish_sport/basketball and then the client asks for publish_sport/+ =20 If tennis and basketball are the only topics under sport, then this is a = valid request.=20 But, if the topic hierarchy is changes during the connection time (adds = sport/baseball) then subscriber gets PUBLISH messages for something they = should not.=20 When topic subscriptions are not protected, the broker would send = anything at the single level for sport/+ and would not worry about the = new additions after the subscription.=20 =20 When topic subscriptions are protected, the Broker can choose to do two = things: 1) Allow the subscription but internally subscribe the clients to = sport/basketball and sport/tennis only. or 2) Reject the subscription and the client needs to ask for subscriptions = that are a subset or equal to their permission strings. So the client = specifically needs to ask for publish_sport/tennis and = publish_sport/basketball matching its scope strings. But then scope = parameter cannot be optional and must be included in the AS response.=20 or 3) Allow the subscription, when a new level is added, check the = permissions of all active subscribers, send DISCONNECT if the current = permissions do not apply to the new hierarchy.=20 =20 1 would need to be again signalled to the client, 2 might be too = restrictive, and 3 may introduce a processing load if things are = changing all the time (which I do not expect).=20 Leaning towards 3... Any thoughts? =20 [JLS] My first thought was to run and hide. I think you have the scope = strings setup wrong, they all should be =E2=80=9Csubscribe_=E2=80=9D not = =E2=80=9Cpublish_=E2=80=9D as a client is never going to ask to publish = with a wildcard (MQTT-3.3.2-2). I would far prefer that the answer = be 2 rather than 1 and I think that 3 is right out. =20 For 3 you are saying we are going to subscribe you, and then potentially = disconnect you at a later time for something you never heard about. I = don=E2=80=99t really care about 1, only because there is no way to = communicate this information back to the client that one is changing the = set of subscriptions that was requested. =20 =20 I am not sure what you are requesting in terms of returning the scope = parameter. The current OAuth specification states that if the = Authorization server returns a token that contains a different scope = that the one requested by the client, then it is required to return the = modified scope to the client. Is that what you are looking for. =20 Jim =20 =20 --Cigdem =20 =20 =20 =20 =20 Jim =20 =20 --Cigdem=20 Jim _______________________________________________ Ace mailing list Ace@ietf.org =20 https://www.ietf.org/mailman/listinfo/ace ------=_NextPart_000_012B_01D5CD6C.4C8D0510 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: = Cigdem Sengul <cigdem.sengul@gmail.com>
Sent: = Wednesday, January 15, 2020 4:44 AM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: = draft-ietf-ace-mqtt-tls-profile@ietf.org; Ace Wg = <ace@ietf.org>
Subject: Re: [Ace] = draft-ietf-ace-mqtt-tls-profile - Validating a subscription is in = scope

 

Hello,

 


It gets interesting when the scope is more = restricted than the subscription = request. 

For instance, the scope is = sport/+

But subscription is = sport/#

 

Should this be refused? = Obviously the subscriber is attempting to subscribe to more than it has = permission for. But does the broker still allow the subscription but = reduce it to = "sport/+"? 

 <= /o:p>

[JLS] Given = that this is not defined in the base MQTT specification, most clients = would not expect this if the ACE is grafted on the side of the = program.  I would therefore say this is a =E2=80=9Cnot = authorized=E2=80=9D and go on.

 <= /o:p>

 

[CS] Agreed. Another issue that we should say = something about is the case when multiple permission strings aggregated = together gives enough permission to the subscription request, based on = the _current_ topic hierarchy. 

Example:

Scope strings in the token were: = publish_sport/tennis  = publish_sport/basketball

and then the client asks for = publish_sport/+

 

If tennis and basketball are the only topics under = sport, then this is a valid request. 

But, if the topic hierarchy is changes during the = connection time (adds sport/baseball) then subscriber gets PUBLISH = messages for something they should = not. 

When topic = subscriptions are not protected, the broker would send anything at the = single level for sport/+ and would not worry about the new additions = after the subscription. 

 

When topic subscriptions are protected, the Broker can = choose to do two things:

1) Allow the subscription but internally subscribe the = clients to sport/basketball and sport/tennis = only.

or

2) = Reject the subscription and the client needs to ask for subscriptions = that are a subset or equal to their permission strings. So the client = specifically needs to ask for publish_sport/tennis and = publish_sport/basketball matching its scope strings. But then scope = parameter cannot be optional and must be included in the AS = response. 

or

3) = Allow the subscription, when a new level is added, check the permissions = of all active subscribers, send DISCONNECT if the current permissions do = not apply to the new hierarchy. 

 

1 = would need to be again signalled to the client, 2 might be too = restrictive, and 3 may introduce a processing load if things are = changing all the time (which I do not = expect). 

Leaning = towards 3...  Any thoughts?

 

[JLS]=C2=A0 = My first thought was to run and hide.=C2=A0 I think you have the scope = strings setup wrong, they all should be =E2=80=9Csubscribe_=E2=80=9D not = =E2=80=9Cpublish_=E2=80=9D as a client is never going to ask to publish = with a wildcard (MQTT-3.3.2-2).=C2=A0=C2=A0 =C2=A0=C2=A0I would far = prefer that the answer be 2 rather than 1 and I think that 3 is right = out.

 

For 3 you are saying we are going to subscribe you, = and then potentially disconnect you at a later time for something you = never heard about.=C2=A0 I don=E2=80=99t really care about 1, only = because there is no way to communicate this information back to the = client that one is changing the set of subscriptions that was = requested.=C2=A0

 

I am not = sure what you are requesting in terms of returning the scope = parameter.=C2=A0 The current OAuth specification states that if the = Authorization server returns a token that contains a different scope = that the one requested by the client, then it is required to return the = modified scope to the client.=C2=A0 Is that what you are looking = for.

 

Jim

 

 

--Cigdem

 

 

 

 

 

Jim

 <= /o:p>

 <= /o:p>

--Cigdem&nbs= p;


Jim
<= br>
_______________________________________________
Ace mailing = list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

------=_NextPart_000_012B_01D5CD6C.4C8D0510-- From nobody Fri Jan 17 19:33:43 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8DA120041; Fri, 17 Jan 2020 19:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1R-40z3uGUEj; Fri, 17 Jan 2020 19:33:39 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1E4812008C; Fri, 17 Jan 2020 19:33:38 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 17 Jan 2020 19:33:34 -0800 From: Jim Schaad To: 'Marco Tiloca' , CC: References: <01b401d59f2e$ff406560$fdc13020$@augustcellars.com> <000001d5c8f1$6b0c7630$41256290$@augustcellars.com> In-Reply-To: Date: Fri, 17 Jan 2020 19:33:31 -0800 Message-ID: <013201d5cdb0$100f3d30$302db790$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQI4jLavukz0j9XyZB28pLOfckduegK6NarEA4bum9gBpSJUdabrE0PQ X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] remarks on draft-tiloca-ace-oscore-gm-admin-00 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 03:33:42 -0000 -----Original Message----- From: Marco Tiloca =20 Sent: Wednesday, January 15, 2020 9:21 AM To: Jim Schaad ; = draft-tiloca-ace-oscore-gm-admin@ietf.org Cc: ace@ietf.org Subject: Re: [Ace] remarks on draft-tiloca-ace-oscore-gm-admin-00 Hi Jim, Thanks for your reply, see more comments inline. Best, /Marco On 2020-01-12 03:38, Jim Schaad wrote: > > -----Original Message----- > From: Ace On Behalf Of Marco Tiloca > Sent: Wednesday, January 8, 2020 8:08 AM > To: Jim Schaad ;=20 > draft-tiloca-ace-oscore-gm-admin@ietf.org > Cc: ace@ietf.org > Subject: Re: [Ace] remarks on draft-tiloca-ace-oscore-gm-admin-00 > > Hi Jim, > > Thanks a lot for this review! > > We have been working on an updated version accessible at [1], which is = already taking into account your comments on CoRAL. > > Please, find below inline some more replies and open points. > > Best, > /Marco > > [1] > https://gitlab.com/crimson84/draft-tiloca-ace-oscore-gm-admin/blob/v-0 > 1/draft-tiloca-ace-oscore-gm-admin.md > > On 2019-11-20 00:13, Jim Schaad wrote: >> This is just going to be a high level review on how things are done=20 >> rather than a detailed review on each line of text. >> >> 4. Are you making it a requirement that the group name be the same=20 >> as the group identifier assigned by the "group_name" parameter? If=20 >> so then having some type of title and description would seem to be = almost mandatory. > > They are in fact the very same thing. The "group_name" parameter = specifies the group name, as intended to identify the OSCORE group both = by the administrator and the joining nodes in the other related = documents. We can use only "invariant name" rather than "invariant = identifier". Are we missing something? If so, what do you suggest we = should give a title and description to? > > > If you are looking at "group_name":"GP00123", then as a configuration = agent it is difficult to know just what this group is supposed to be. = In this case some type of title or description helps to figure that out. We can add a new group configuration parameter 'group_title', as a CBOR = text string. This specifies a human-readable descriptive name of the = group, suggesting what it is about. [JLS] Sounds like a logical thing to do. > >> 5. There needs to be some parameters around pointing to the correct=20 >> AS and so forth. The management API may reject because it does not = trust the AS. >> Don't assume that this is a single value for the AS either. > > This is good and also aligned with other related drafts. > > If we interpret your suggestion correctly: > > 1) The POST request to /manage may specify also an optional 'as_uri' > parameter, with the link to a suggested AS. The GM may accept the = suggestion or not. If not, it has to think of an alternative AS, as = valid issuer of tokens for joining that group. > > 2) The GM must have one more parameter in the group configuration with = the effective AS URI, i.e. either one provided by the administrator and = accepted, or one otherwise decided. > > Do you think of any additional related parameters to be included in = the POST request, other than 'as_uri'? Perhaps the public key of the = suggested AS if applicable? > > Do you think the suggestion in the request should actually be a list = of AS, out of which the GM may pick up at most one? > > > I have put something into draft-schaad-core-reef which starts thinking = about this. I think that we need to sit down and do a brainstorming = session to figure out what items should/should not be put into such a = structure. > With pleasure, and thanks for the pointer :-) Out of my hat, I can think of: the URI of one AS and its /token = endpoint; the profile(s) that the Group Manager have to use (if it = supports them) for letting joining nodes enter the group; the public key = of the AS if applicable; the ACE audience that the Group Manager has to = use for this group. [JLS] One of the things that needs to be remembered is that this does = not have to be flat, so there can be a clean separation between an AS = and a GM. >> 6. You are missing a lot of management detail on the POST to the=20 >> group node. Some of the things that are missing would be: >> a) Is the group active or inactive > > We can have one more parameter on the group-configuration resource for = this. > > We are interpreting active/inactive as follows. Ideally, upon creating = the group, the request can specify the initial status as active or = inactive. Upon later updating the group by sending a request to the = group-configuration resource, the administrator can change the status = (or read it through a GET). > > Then the active/inactive status has two parallel scopes: > > 1) one scope is for the GM alone, i.e the GM would allow the joining = of new group members only if the group is set as active. > > 2) when the group is set as inactive, the current group members should = refrain from sending and should not expect receiving any message = protected with that group key material. However, there is no way to = actually force them to. > > In support to scope (2), when the status changes to inactive, the GM = should inform group members about that. To this end, the = group-membership resource intended for group members would also include = a parameter reflecting the group status and aligned in value with the = one in the group-configuration resource. Then, there are two ways to = inform the group members of a status change. > > a) A way is to have the group members observing the group-membership = resource (that they may have been doing already anyway for = notification-based rekeying). > > b) A second way is for the group members to have a dedicated local = resources for this (and other) kind of control communication (e.g. > rekeying). This is something we are also considering in > ace-key-groupcomm(-oscore) for receiving individual rekeying messages. > In either case this would require either: i) each node to provide the = GM with the URI to such local resource, in the join request; or ii) the = GM to include in the join response to each joining node a same multicast = address targeting a local resource that that node has to create to = receive control messages. > > > I don't remember for sure what I was thinking about when I wrote this. = I think that I was more interested in if one can or cannot join a group = when it is inactive and what happens. If you set a group to inactive, = are all members of the group removed or does the group just stop issuing = new keys? Building on the previous reply, an inactive group would mean that: i) no = new members are admitted, thus no new keys to new members; ii) stop = issuing new keys for current members; iii) current members are expected = to stop communicating (which should rely on informing them) but are not = removed. So the group is temporarily inactive but still exists. > >> b) How does the server react if you change a the content encryption=20 >> algorithm, is this a simple re-key operation or is it more=20 >> complicated > > An easy answer would be rekeying the group, just as for any other = triggering reason. I agree this should be mention in this draft. > > However, I think a more elaborated description of what happens if the = algorithm is changed (regardless why and how) should be actually better = given in oscore-groupcomm (the what) and in ace-key-groupcomm-oscore = (the how). > > > Punting to a different document is fine as long as it really is there. = However, this is the place where it appears to be changed by an = external source and thus seems to be a good place to talk about it. Agree, this document is in fact acting as a use case of its own for = this. >> c) How does the server react if you change the signature algorithm? =20 >> This would seem to be a much harder thing to do if the group is not=20 >> empty or not active as everybody is going to need to re-join. > > Right. If the signature algorithm changes, the current public keys may = be not compatible with it any longer. We see the following possible = ways, assuming the current group members have learnt of the new = algorithm in use. > > 1) The hard way, i.e. everyone leaving and re-joining. > > 2) A more lightweight way, i.e. relying on yet another operation for = current group members on the GM, to upload a new public key consistent = with the new algorithm. This would require to proof possession of the = corresponding private key, as it is done upon joining. Probably, in this = case, this can happen like we do in the Group OSCORE profile of ACE = between the Client and the AS, see the bullet point on = 'client_cred_verify' at [2]. > > And again it looks like details on the way this is done fits better in = other documents. > > [2] > https://tools.ietf.org/html/draft-tiloca-ace-group-oscore-profile-01#s > ection-3.1 > > > > See comment above. As above, yes, something should be said here. Formally, the extended = keying material is distributed as in a rekeying, but the only difference = would be the signature algorithm. This is enough for the group members = to understand what happens and what to do. If they leave and fully join again, it's just about following the same = procedure of ietf-ace-key-groupcomm oscore. The alternative (2) above = would require one more functionality exported by the Group Manager for = current group members to upload a new and compatible public key (and = this has to be followed by proof-of-possession). This may be achieved = with a new PUT handler to the group-membership resource = group-oscore/GROUPNAME/pub-key (see https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-04#sectio= n-8 ) > >> d) Other parameter that are changed may be just as bad as changing=20 >> the signature algorithm - how the re-key is done jumps immediately to = mind. > > Yes, changing HKDF/Alg results in what discussed two replies above; = changing anything else (thus related to signatures) results in what = discussed in the reply above. > > > Much of this may go to say that changing this parameters kicks = everybody off the group and restarts from scratch. It seems better to leave the burden of a clear decision to the = Administrator. That is, if the Administrator has good reasons to update = those parameters, even though a rekeying will follow, so be it. Or, the = Administrator can delete the group altogether and create it again, if = believed to be better. On the other hand, it sounds better to avoid that the Group Manager = itself decides to delete a group. > >> 7. Is there currently any way for a KDC to signal to all of the=20 >> members that have joined that the key group no longer exists? A=20 >> DELETE would seem to indicate the need to be able to do this. > > Right, the DELETE of a group-configuration resource would trigger=20 > something like this. The current resource maintaining on the GM=20 > consists > in: destroying both group-configuration and group-membership resource, = then reply to the Administrator. > > That said, a possible extension to also inform current group members = is akin to what we describe above about signaling that the group has = moved to inactive state. That is: > > i) if group members observe the group-membership resource, a 4.04 = notification is sent to them, upon deleting that resource. > > ii) if group members have their own local resource to receive control = messages from the GM, a control message can inform about the deletion of = such group-membership resource. This would be particularly convenient to = be sent over multicast. This method (ii) would actually require the GM = to send these messages to the group members first, and only afterwards = actually delete the group-membership resource, in case information such = as the destination addresses and URIs to consider are stored as part of = the group-membership resource itself. > > A group member can of course discover what happened at any time, just = by sending any type of request to the deleted group-membership resource = and getting a 4.04 response back. > > The actual difference between an existing inactive group and a deleted = group is that the latter has no way back, and would need to be = re-created from scratch on the GM by the Administrator. > > > Also could say that you can only delete a successfully inactivated = group. Ok, this has two consequences: 1) We can add one more group-configuration boolean parameter 'active', = that the Administrator also controls. 2) Before issuing a DELETE to delete a group, the Administrator has to = change 'active' to FALSE, and get a confirmation response from the Group = Manager. However, I wonder what you mean with "successfully". What can make the = Group Manager fail/hold from changing 'active' from TRUE to FALSE when = requested to do so by the Administrator? [JLS] I think that I got the successfully on the wrong item - should be = on the delete not the group. Jim > > Jim > > >> Jim >> >> >> > -- > Marco Tiloca > Ph.D., Senior Researcher > > RISE Research Institutes of Sweden > Division ICT > Isafjordsgatan 22 / Kistag=C3=A5ngen 16 > SE-164 40 Kista (Sweden) > > Phone: +46 (0)70 60 46 501 > https://www.ri.se > > > -- Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se From nobody Sat Jan 18 08:22:35 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F051200D5; Sat, 18 Jan 2020 08:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqKhgcRDFjK0; Sat, 18 Jan 2020 08:22:32 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35064120077; Sat, 18 Jan 2020 08:22:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1579364499; bh=uLKBX3wAYDu4zWDUFbG2/2tBbuYoqyEY4fOtYuPOQ4o=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=crC7Fr335tWHrbECtiLkv/fhDRaOtC45M6zSQbkTgfxoFsRZZN1e5U3K5gn+LnJTi 92CtRc7vw1n6ip1N1yBdtAlARqjcbcZ7RD+9IcJozRrImGBjPiE53Mkt8H6rjWe9y9 kCq9TDEEJsKl9eEIMB8iPAXy8OpoPhbPs8CXQcO0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.220] ([84.217.44.37]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MtfNf-1jmLSG0R5j-00v5AK; Sat, 18 Jan 2020 17:21:39 +0100 To: Brian Campbell , Seitz Ludwig Cc: Roman Danyliw , "jwt-reg-review@ietf.org" , Jim Schaad , The IESG , "ace@ietf.org" , "drafts-lastcall@iana.org" , Benjamin Kaduk References: <9c32d171-9a4a-ba71-c989-92a177d9e989@gmx.de> <14a3c79d23e94d938be4a173a6c8256d@combitech.se> From: Ludwig Seitz Message-ID: <504e86ae-f577-8526-e1cb-ed38d6a2e36f@gmx.de> Date: Sat, 18 Jan 2020 17:21:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:dI9ohEOYpq5JbaOlk9y3LS9i+TT/kzr4xRI9e6PqHGbEfdfA9K+ DC5vvQqvMK8CQ5fdpgrJuMZjfH/bm3tHgV90PrYJPFbMwC6FCY/fY+t9j+2h65tJneEjhVn 1k5okJltFVFzLJcErDJRXPQ9Br8IT+4FDWRVQHG416Y05/OMNQWF1nkvGhb1jadEcowYpUe 2Y4o3m+WJGXurdz7O7WfA== X-UI-Out-Filterresults: notjunk:1;V03:K0:k9/hm0fTxC4=:pJUpqdm3f0UGvGq0ZsyYNR ELi13r/4yy+nW+NT/JokNxfly6OI6g4GiZaJPkIQsXRtARBu7YipK+ezmZf1Sw7AsLztHkJMq qRhRxerx34ysNp61oFSN6i6R/pvriyds20DzqUNT/q86pSdL8wpaFlIVi0KakrcwD+aMlK9T/ q9g53YjYNus/EegTNh68W6yUXT2ziOKEafUG1KD4sGxBJD2rTKzKMwLrAnIF4R/i/JYAYyt9y x4KblbqYkuHmcMju0BT7u4/yKeFVMissK9CKFinbW3ZUU0BJjVLEd4l8lhqvXKuVR+d149Hku 3kLbs9VHUZ/pgmVGXERI7vvqXsSc7ROsZORf9FhPwab8jLU/UbjALj4l53Qq1jk2tHkyYa6G+ /sNkD1Dp9hy3cNzoO+Yynwk0Qdo25LLaoRbOFL/Y0CP7ZIG/O0AIeqqbhIFTZrYyXHaCao5Di sq51tciz8ufgk/PeGRM3C7NsTRzJ7T87NbfO9mRU/TfDHiJFMyS4vOwVC/38R4PAU2PBQzcML 0vFpyxznDNUP9w5m/Oueo1OEqyz7Jlu0DJD0zc/AaM7InTqgTuNMf0NiBM0OuGH/u2XXjkHVz nvQ2kVIKdivNFQivdWiwGRPBTDT5gLuUNR5JFCf+OF7gxCXSBEwVnfYuxN4SlzMZV2+BFPCfK LGwqBf5zVyjlXLY80xBkrb2AS8NqC9RoC6KrdwBv5OqigYvECsvOQTzTsdgPiiYYCFOX0shEi f8DyNVL9rsY9d+TUv3O5gk4iIqizdBTtxP3Qi1StqZbXR2w/BSEBz3a4UTf6Almsog768SRz7 zt+tDJ34HWavt72GEmfvf4ZaY3G9ILAgcksNBsGPY+lYGxR+LzFFoTcJAo8aoWyviTSC0SMzA 9m6QO8pu14xlt6y3982lEUGQvVNTfeticZd5rekRGOBlQfdlh9CHRU0sPmVuRFkGy2PkioQkp MFuJgmW+3Hzt8riVuJa2cGLZDFVaMVBDYq74x5a2Ofr2TIVe1IOE5n07Kl5MDM6YUjHoojN16 2OfKKrumYU3ezhiKpCMVtROwMGxdT/sQXa0bsoMnxWTVszXkZHxx9ltpvpunRPjWjVtKfWrmm h1rHjUQPy4ECCLTHlotI85m5mTCWRacd60q9o4YPZ3vPAe+iYJVf3pZuwGGd93Era1M25AvIn 8ReUVwthdUiIawATKotaZdTWK/MFrcGiUkIH6wSXOKNF+uCjeej6uGfpjtuikxiZLvBc/h/a9 F2OnTXgbjkVQashKAroI1pFkhSZMgr+SyIEIqnw7jomMN3SgDJclEVI5PJSc= Archived-At: Subject: Re: [Ace] [Jwt-reg-review] Requested review for IANA registration in draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 16:22:34 -0000 On 2020-01-13 22:01, Brian Campbell wrote: > Thanks for the updates Lugwig, > > Section 6.6. does propose one mitigation for the unbounded memory growth > problem. However, it relies on the AS to do pretty specific things with > the content of other claims for it to even be possible for an RS to > perform the mitigation approach. Do you think, for interoperability, it > needs to be more prescriptive? Like maybe requiring the cti/jti claim > with specific content and characteristics when exi is present or > embedding/encoding that sequence number in the value of the exi itself > alongside the lifetime of the token. > > This sounds like a reasonable requirement. I'm even inclined to make that a MUST and not just a SHALL. Next update coming soon. /Ludwig From nobody Sat Jan 18 08:52:19 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8BC12002F; Sat, 18 Jan 2020 08:52:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <157936633802.31607.5853112364202588413@ietfa.amsl.com> Date: Sat, 18 Jan 2020 08:52:18 -0800 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oauth-authz-31.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 16:52:18 -0000 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 : Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) Authors : Ludwig Seitz Goeran Selander Erik Wahlstroem Samuel Erdtman Hannes Tschofenig Filename : draft-ietf-ace-oauth-authz-31.txt Pages : 87 Date : 2020-01-18 Abstract: This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE- OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-31 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-31 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-31 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/ From nobody Sat Jan 18 08:56:24 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFF512002F for ; Sat, 18 Jan 2020 08:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwW1vWqj9inB for ; Sat, 18 Jan 2020 08:56:19 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D451412003E for ; Sat, 18 Jan 2020 08:56:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1579366574; bh=083z31fT//M0sXQyY5Xh440zrDs3gjAOYTchQJQvj9c=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=d5Mv+gWUPwxnDakzR4tIHBJgX9TPanmKCqFaWSxa6f1TJ2za/SBupVG0mJjBOO7O8 yVz2QA00p97Np0z3TR3+7/Nk14FWqlv4fZVGi9hZ8ZF82dLEYDbOpMJy7/dUl/d/jH PVcJsqUmeku+5Ojopte8Wp6dMHouMvLh05jYqCXQ= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.220] ([84.217.44.37]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MFKGP-1iqKHc4A93-00Fm7u for ; Sat, 18 Jan 2020 17:56:14 +0100 To: ace@ietf.org References: <157936633802.31607.5853112364202588413@ietfa.amsl.com> From: Ludwig Seitz Message-ID: Date: Sat, 18 Jan 2020 17:56:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <157936633802.31607.5853112364202588413@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:M73i8TfAfuyyvdVl+4+R7yOFFFk8KXgUK9N5n9imJgWIWKreSwq SbiMNTxreJZLufxa3voTkKejMCIBodphQoajOLLWM8lAgW+PXUS7P6OpJauXaRYIs4C5vdQ 6S0QWLHYwTL+nh9EFDoISyyP724rq7/sPr7VdCkqbgQSkFqzz02VhCQtgKLK+t2TLWwvLSH 9VI/Bm7c9JDoTbl5jrs4w== X-UI-Out-Filterresults: notjunk:1;V03:K0:gwJdgjpUzTs=:qAYnLD+nrJNFWaL9ZYrk3L akKMkREOPZJniZkKugPJ1irvuzttWjpYtOWqXZCoGvjB54OnmCcssCLC00DTJ/Mswr1Pv+rS+ xKPdtlqwtbltFfeh8ZeongNQi00S+GQzqGwCmj23A0dUqN2jg8C9rFANj9eel8lcI09LbgSp0 m1SmcCgfxqyUtTS+0J9geMWuESx13l7tt4nXPQo5dWs5IMv9s9WUTIc8dbYhKgNM3ifrdykCY YHVO/YbyMpUGQ1m+LRnKRNaLmb2+0hJyTLq/nbIbnFV4E/axMR5jHtdptCI5TFq2q4SJyDVF9 +biBFKNcQzdqtiOjbyrHKOV40Zbx8um3Iz5oDvQvR0QVoZ1XvoLZx3t/NlUkbcTNNBrFNg4n6 CCQlzYhsxCUykJkeqrXHeh0Lf8r5bI9IaeMpJSqHYOwdoq3nK3hAnHD/pgdzraqI/97aoOrxA cx9vCMXKHZRS3jHSnd0SpZgSwc9o3jt05EzoRg/Ce5JG5sYU11rDBEW+QE65hg+az5LWou8DI LhBCJ259258VIUSj9LJA+ofiU5OdQTDqk5jf94HjnlQJ9WtRduNXOedrf/uO2w5B+ZLd72lig WHSdCcRgx9lABxH/c9WTx3CI+Te3PEwh3qxXIv5+BNIYu67h32AiYjf5lARMw1jQdv5RCWY6m x/Yh49hp7IvEU7ckBZUerHSCf484ClV0IVY/1Gh9XsD/mhBMQ70y10cRURQ9/mXmQYTrsIoLn 4z4HBipo5z6otLP0NjE5xHp+DtaXJOT6xgGBLuklgOFgWy0g0fzDVMHgqB8YhSEjHqo7TlmDV 9w07zwrJBvmkI6RKSN/DM8+jYSU3BvREipSYI+vM7J9c30/4MoVXLzAenAn3o4TjJMIHcckZF fIEK8mytoS9dbNK6YpVxrobNC1klbVY86Ir4WjqmISwRrY5FxI1nDPx73ZUnQSfjmKTglPtcm qRH/Fe5mJoT3isMoiHsiA7Tkeu7YPuiVZqlsMaoMaIOSo4JC66lVi8V9MVVAW78a6b2BLeApe Y/MQIqqgaofdQS25UcCDszWzTFzdZKqoEfat1oRyD62jufIPvSHCLVmBeIy9FcYJ/olIs9ndn dVgN2aJL4fu6bIS/OFcBMSHfJdCf3Vwljn3qOTax87h3ZHBZL+EES9eUAa4p4jUa8RWW+79ge oyL1aWZcAyFjO5QpB1QAEOgJkeYzaFY+D41Rp1vx/CZchye9229T/MPQNguA2l37KHYLgyyJP wI1H9kOgKTKT4jU09XSFPCg88r9eoXTfD5YYtevagHYN1wovoRZJ9nzB20nU= Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-oauth-authz-31.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 16:56:21 -0000 Hello ACE, this update implements the changes to the 'exi' claim recommended by Brian Campbell. /Ludwig On 2020-01-18 17:52, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. > This draft is a work item of the Authentication and Authorization for Co= nstrained Environments WG of the IETF. > > Title : Authentication and Authorization for Constrai= ned Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) > Authors : Ludwig Seitz > Goeran Selander > Erik Wahlstroem > Samuel Erdtman > Hannes Tschofenig > Filename : draft-ietf-ace-oauth-authz-31.txt > Pages : 87 > Date : 2020-01-18 > > Abstract: > This specification defines a framework for authentication and > authorization in Internet of Things (IoT) environments called ACE- > OAuth. The framework is based on a set of building blocks including > OAuth 2.0 and the Constrained Application Protocol (CoAP), thus > transforming a well-known and widely used authorization solution int= o > a form suitable for IoT devices. Existing specifications are used > where possible, but extensions are added and profiles are defined to > better serve the IoT use cases. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-31 > https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-31 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-oauth-authz-31 > > > Please note that it may take a couple of minutes from the time of submis= sion > 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 > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > From nobody Sun Jan 19 15:35:31 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F0112004D; Sun, 19 Jan 2020 15:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TD3CytTO6EoK; Sun, 19 Jan 2020 15:35:21 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC04D12001E; Sun, 19 Jan 2020 15:35:20 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 19 Jan 2020 15:35:12 -0800 From: Jim Schaad To: 'Brian Campbell' , 'Seitz Ludwig' CC: 'Ludwig Seitz' , 'Roman Danyliw' , , 'Daniel Migault' , 'Benjamin Kaduk' , , References: <4a5177af-a442-f109-f620-0ae91953eb63@gmx.de> <2616175d102b4c19a60c6a79d4256b5e@combitech.se> In-Reply-To: Date: Sun, 19 Jan 2020 15:35:10 -0800 Message-ID: <018601d5cf21$19cec7b0$4d6c5710$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0187_01D5CEDE.0BAC4B00" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQEhd6Yle2bwoestBETa2w8Xfe67igHXMmInAunJ6fMCAFODFgH28139AnlL6EWpAbvhkA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2020 23:35:24 -0000 ------=_NextPart_000_0187_01D5CEDE.0BAC4B00 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have managed to merge most of my code that deals with the confirmation = claim and I have ended up with a single problem when dealing with = confirmations. If this is going to get fixed, it needs to get fixed in = draft-ietf-ace-cwt-proof-of-possession prior to this document finishing = processing the EDIT process in the RFC editor. =20 All of the items that can appear in a confirmation claim are unique = except for the =E2=80=98kid=E2=80=99 claim method. This field is = defined as being a text field for JWT (RFC 7800), but it is defined as = being a binary field for CWT. It is a text field when defined in RFC = 7800. I do not anticipate any issues for the definition of a thumbprint = as COSE is using a very different format for the definition of = thumbprints which will led to a different naming convention. =20 Jim =20 =20 =20 From: Brian Campbell =20 Sent: Monday, January 13, 2020 10:01 AM To: Seitz Ludwig Cc: Ludwig Seitz ; Roman Danyliw ; = oauth-ext-review@ietf.org; Daniel Migault ; = Jim Schaad ; Benjamin Kaduk ; = ace@ietf.org; drafts-lastcall@iana.org Subject: Re: [Ace] Requested review for IANA registration in = draft-ietf-ace-oauth-params =20 Thanks Ludwig, =20 On Sat, Jan 11, 2020 at 8:20 AM Seitz Ludwig > wrote: [snip]=20 =20 From: Ace > On = Behalf Of Brian Campbell =20 [snip] =20 So in -09 the "cnf" Introspection Response Parameter was the following = the syntax of the "cnf" claim from PoP Key Semantics for CWTs = [ID.ietf-ace-cwt-proof-of-possession] and in -10 it's following the = syntax of PoP Key Semantics for JWTs [RFC7800] transitively via = [I-D.ietf-oauth-mtls] reference. I think I understand that the two PoP = key semantics documents are conceptually the same or similar. But I = don't know that the syntax is the same? Figure 5 = = is pointed to for mapping between CBOR and JSON but it only has mappings = for the main top level parameters. Maybe I just don't get it or am = missing something... =20 =20 [LS] No you are not missing something, I just got sloppy trying to do a = quickfix. =20 Background: The reason for defining both JSON and CBOR-based = interactions is that you might have a powerful client communicating with = a constrained RS. The client does vanilla OAuth interactions with the AS = via the token endpoint, but is served a CWT and associated ACE = parameters (cnf, ace-profile, =E2=80=A6) for interaction with the RS.=20 The pop-key should decode to the same binary representation regardless = of whether it came in a JSON or CBOR wrapper. =20 Okay, so noting that there is cnf content that doesn't decode to a key, = I suppose I'll just take it on faith that all the relevant or expected = usages involve a key that can be represented in both CBOR and JSON.=20 CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. ------=_NextPart_000_0187_01D5CEDE.0BAC4B00 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I have = managed to merge most of my code that deals with the confirmation claim = and I have ended up with a single problem when dealing with = confirmations.=C2=A0 If this is going to get fixed, it needs to get = fixed in draft-ietf-ace-cwt-proof-of-possession prior to this document = finishing processing the EDIT process in the RFC = editor.

 

All of the items that can appear in a confirmation = claim are unique except for the =E2=80=98kid=E2=80=99 claim = method.=C2=A0 This field is defined as being a text field for JWT (RFC = 7800), but it is defined as being a binary field for CWT.=C2=A0 It is a = text field when defined in RFC 7800.=C2=A0 I do not anticipate any = issues for the definition of a thumbprint as COSE is using a very = different format for the definition of thumbprints which will led to a = different naming convention.

 

Jim

 

 

 

From: = Brian Campbell <bcampbell@pingidentity.com>
Sent: = Monday, January 13, 2020 10:01 AM
To: Seitz Ludwig = <ludwig.seitz@combitech.se>
Cc: Ludwig Seitz = <ludwig_seitz@gmx.de>; Roman Danyliw <rdd@cert.org>; = oauth-ext-review@ietf.org; Daniel Migault = <daniel.migault@ericsson.com>; Jim Schaad = <ietf@augustcellars.com>; Benjamin Kaduk <kaduk@mit.edu>; = ace@ietf.org; drafts-lastcall@iana.org
Subject: Re: [Ace] = Requested review for IANA registration in = draft-ietf-ace-oauth-params

 

Thanks Ludwig,

 

On = Sat, Jan 11, 2020 at 8:20 AM Seitz Ludwig <ludwig.seitz@combitech.se> = wrote:

[snip]

 

From:= Ace <ace-bounces@ietf.org> On Behalf Of Brian = Campbell

 <= /o:p>

[snip]

  =                  =

So in -09 = the "cnf" Introspection Response Parameter was the following = the syntax of the "cnf" claim from PoP Key Semantics for CWTs = [ID.ietf-ace-cwt-proof-of-possession] and in -10 it's following the = syntax of PoP Key Semantics for JWTs [RFC7800] transitively via = [I-D.ietf-oauth-mtls] reference. I think I understand that the two PoP = key semantics documents are conceptually the same or similar. But I = don't know that the syntax is the same? Figure 5 is pointed to for mapping between = CBOR and JSON but it only has mappings for the main top level = parameters. Maybe I just don't get it or am missing something...   =

 <= /o:p>

[LS] No you are not missing something, I just = got sloppy trying to do a quickfix.

 

Background: The reason for defining both JSON = and CBOR-based interactions is that you might have a powerful client = communicating with a constrained RS. The client does vanilla OAuth = interactions with the AS via the token endpoint, but is served a CWT and = associated ACE parameters (cnf, ace-profile, =E2=80=A6) for interaction = with the RS.

The pop-key should decode to the same binary = representation regardless of whether it came in a JSON or CBOR = wrapper.

<= p class=3DMsoNormal> 

Okay, so noting that there is cnf content that doesn't = decode to a key, I suppose I'll just take it on faith that all the = relevant or expected usages involve a key that can be represented in = both CBOR and JSON.


CONFIDENTIALITY NOTICE: This email may contain = confidential and privileged material for the sole use of the intended = recipient(s). Any review, use, distribution or disclosure by others is = strictly prohibited.  If you have received this communication in = error, please notify the sender immediately by e-mail and delete the = message and any file attachments from your computer. Thank = you.

------=_NextPart_000_0187_01D5CEDE.0BAC4B00-- From nobody Mon Jan 20 14:23:25 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271F8120045; Mon, 20 Jan 2020 14:23:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUDtpB85aggh; Mon, 20 Jan 2020 14:23:21 -0800 (PST) Received: from mail-vk1-xa29.google.com (mail-vk1-xa29.google.com [IPv6:2607:f8b0:4864:20::a29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B3A712011D; Mon, 20 Jan 2020 14:23:21 -0800 (PST) Received: by mail-vk1-xa29.google.com with SMTP id p191so344473vkf.8; Mon, 20 Jan 2020 14:23:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CKzBi1Sgo566aq1XUgECcb4nDdoHUkAFG78bVr+/Nx8=; b=HcL50fT9K31tbxemE/jxW0IT32of6sk3LuBSkwmuu63DiBtgKYBT1zoj8IIzlYYyaW eA0+V765/eg8X/Rk54/0X/kBWTqjO0jcQ5ip9DbA41dnFWZ9BLw9CXEacmt25IrRty75 hqdTe/7Fjl8LwfyQOA1V6SDH3jpHCpFNSU1DiXyM0nFnD8023N3Mdyyx2cV8A1Bxho5o pp3K9DInyiNl8bwm0Cv7jbWakyl3rKUnlc1dRtzyRxvEfGB6z9YewsxC/q1FcFWkC57P ji0iTgosl1kxk9ORclWGOn0kH55tlVqHZKvtaD9rg+HG7Trbb6fjQw3aksbP8Qg6qA9/ Zv1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CKzBi1Sgo566aq1XUgECcb4nDdoHUkAFG78bVr+/Nx8=; b=LNym3sbFNj3DApy3E/Dtvha/jlcoZcMdt+AG8S2/PS33RNQFQkElDFm3HKOM9iN65o WxLyhfBn+5NIXPOZC9HMusBRfn9k1EYBM5hAdf4gKjHSBy6g3uN5GyTWVPzsXofKfneY A1QR9SEDW/bwyvdx0ZSe22m2olXj8Q2T97pa4HPwIrUNAzgdfijHeUN7DL9HO99ZZ55c 0Kc7TqaxJLNZyzqrE5wLfAuKtcGg4RZBB6Lt0cKecAQrgX1asgNEz4SfWIIbUoxDXmbc TqHPHqtdA93mTAE10gS0AjdKmtRfUzGaLzP6/UfPwQQW8GvKIrukmBYSmvacS/vnalHO 6k4w== X-Gm-Message-State: APjAAAWX7tmAisob3jp4JBjYZLpcjm4ry5EERyquow6ax7RVaewe6Ab/ mIZ7gtwxCTONBJmYHPngNG9FCg5hVa0Ll7SaJomUs6wl X-Google-Smtp-Source: APXvYqw+h+ruCIgjjdQ505CP3ZiQT4Pf/KgfU48lK/XMEP64jjnBlfBL7Zq09Og/oXpOt+DOfp6De4pI/efHY7h+mAw= X-Received: by 2002:a1f:252:: with SMTP id 79mr1211734vkc.96.1579559000453; Mon, 20 Jan 2020 14:23:20 -0800 (PST) MIME-Version: 1.0 References: <003f01d5c9b2$1fe439b0$5facad10$@augustcellars.com> <00de01d5cafa$adefb420$09cf1c60$@augustcellars.com> <012a01d5cdaf$5aad85f0$100891d0$@augustcellars.com> In-Reply-To: <012a01d5cdaf$5aad85f0$100891d0$@augustcellars.com> From: Cigdem Sengul Date: Mon, 20 Jan 2020 22:23:16 +0000 Message-ID: To: Jim Schaad Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org, Ace Wg Content-Type: multipart/alternative; boundary="0000000000001fb474059c99bd57" Archived-At: Subject: Re: [Ace] draft-ietf-ace-mqtt-tls-profile - Validating a subscription is in scope X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 22:23:24 -0000 --0000000000001fb474059c99bd57 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Jim, > > > > When topic subscriptions are protected, the Broker can choose to do two > things: > > 1) Allow the subscription but internally subscribe the clients to > sport/basketball and sport/tennis only. > > or > > 2) Reject the subscription and the client needs to ask for subscriptions > that are a subset or equal to their permission strings. So the client > specifically needs to ask for publish_sport/tennis and > publish_sport/basketball matching its scope strings. But then scope > parameter cannot be optional and must be included in the AS response. > > or > > 3) Allow the subscription, when a new level is added, check the > permissions of all active subscribers, send DISCONNECT if the current > permissions do not apply to the new hierarchy. > > > > 1 would need to be again signalled to the client, 2 might be too > restrictive, and 3 may introduce a processing load if things are changing > all the time (which I do not expect). > > Leaning towards 3... Any thoughts? > > > > [JLS] My first thought was to run and hide. I think you have the scope > strings setup wrong, they all should be =E2=80=9Csubscribe_=E2=80=9D not = =E2=80=9Cpublish_=E2=80=9D as a > client is never going to ask to publish with a wildcard (MQTT-3.3.2-2). > I would far prefer that the answer be 2 rather than 1 and I think that = 3 > is right out. > Gosh... Don't know why I switched to publish... Sorry for any pain caused! > > > For 3 you are saying we are going to subscribe you, and then potentially > disconnect you at a later time for something you never heard about. I > don=E2=80=99t really care about 1, only because there is no way to commun= icate this > information back to the client that one is changing the set of > subscriptions that was requested. > Ah, I see your interpretation- I saw the subscription request for subscribe_topic/+ and subscribe_topic/# as a request from the subscriber saying "send me anything under x" (depending on +/# restrictions). So, they may not know all the matching subtopics anyway. If the permissions are including the wildcards and cover the request, no problem. But, if they don't but the combination of a subset of permissions do at the current state (i.e., subscribe_sport/basketball + subscribe_sport/tennis =3D subscribe_sport/+), I wondered whether the RS ma= y want to accept this request. However, if it registers this subscription as subscribe_sport/+, it is not future proof for any changes to that level and client would be lacking the appropriate permissions - which should lead to a disconnect. > > > I am not sure what you are requesting in terms of returning the scope > parameter. The current OAuth specification states that if the > Authorization server returns a token that contains a different scope that > the one requested by the client, then it is required to return the modifi= ed > scope to the client. Is that what you are looking for. > Thanks, I was not sure that was a MUST, and I should have read the RFC more carefully. (Possibly I got confused with another spec out of IETF, where the client may not have the final info on the scope.) Then 2 would definitely work and is much simpler. I was thinking it may be restricting. But, it's best to avoid the complexity of additional checks on combinations of permissions to see if the request can be satisfied. Thanks for your feedback. --Cigdem > > > Jim > > > > > > --Cigdem > > > > > > > > > > > > Jim > > > > > > --Cigdem > > > Jim > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > --0000000000001fb474059c99bd57 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Jim,


=C2=A0

When topic subscriptions are protected, the Br= oker can choose to do two things:

1) Allow the subscription but internally subscribe the clients to= sport/basketball and sport/tennis only.

or

2) R= eject the subscription and the client needs to ask for subscriptions that a= re a subset or equal to their permission strings. So the client specificall= y needs to ask for publish_sport/tennis and publish_sport/basketball matchi= ng its scope strings. But then scope parameter cannot be optional and must = be included in the AS response.=C2=A0

or

3) All= ow the subscription, when a new level is added, check the permissions of al= l active subscribers, send DISCONNECT if the current permissions do not app= ly to the new hierarchy.=C2=A0

=C2=A0

1 would ne= ed to be again signalled to the client, 2 might be too restrictive, and 3 m= ay introduce a processing load if things are changing all the time (which I= do not expect).=C2=A0

L= eaning towards 3...=C2=A0 Any thoughts?

=C2=A0

[JLS]=C2=A0 My first th= ought was to run and hide.=C2=A0 I think you have the scope strings setup w= rong, they all should be =E2=80=9Csubscribe_=E2=80=9D not =E2=80=9Cpublish_= =E2=80=9D as a client is never going to ask to publish with a wildcard (MQT= T-3.3.2-2).=C2=A0=C2=A0 =C2=A0=C2=A0I would far prefer that the answer be 2= rather than 1 and I think that 3 is right out.

=

Gosh... Don't know why I switche= d to publish... Sorry for any pain caused!
=C2=A0

=C2=A0

<= p class=3D"MsoNormal">For 3 you are saying we are going to subscribe you, a= nd then potentially disconnect you at a later time for something you never = heard about.=C2=A0 I don=E2=80=99t really care about 1, only because there = is no way to communicate this information back to the client that one is ch= anging the set of subscriptions that was requested.=C2=A0


Ah, I see your interpretat= ion- I saw the subscription request for subscribe_topic/+=C2=A0 and subscri= be_topic/# as a request from the subscriber saying "send me anything u= nder x" (depending on=C2=A0+/# restrictions). So, they may not know al= l the matching subtopics anyway.=C2=A0

If the perm= issions are including the wildcards and cover the request, no problem.=C2= =A0 But, if they don't but the combination of a subset of permissions d= o at the current state (i.e., subscribe_sport/basketball=C2=A0+ subscribe_s= port/tennis =3D subscribe_sport/+), I wondered whether the RS may want to a= ccept this request. However, if it registers this subscription as subscribe= _sport/+, it is not future proof for any changes to that level and client w= ould be lacking the appropriate permissions - which should lead to a discon= nect.=C2=A0
=C2=A0

=C2=A0

I am not = sure what you are requesting in terms of returning the scope parameter.=C2= =A0 The current OAuth specification states that if the Authorization server= returns a token that contains a different scope that the one requested by = the client, then it is required to return the modified scope to the client.= =C2=A0 Is that what you are looking for.

<= /blockquote>

Thanks, I was not sure that was a MUST, and= I should have read the RFC more carefully. (Possibly I got confused with a= nother spec out of IETF, where the client may not have the final info on th= e scope.)=C2=A0

Then 2 would definitely work and i= s much simpler. I was thinking it may be restricting.=C2=A0But, it's be= st to avoid the complexity of additional checks on combinations of permissi= ons to see if the request can be satisfied.

Thanks= for your feedback.=C2=A0
--Cigdem

=C2= =A0
=

=C2= =A0

Jim

=C2=A0

=C2= =A0

--Cigdem

<= /div>

=C2=A0

=C2=A0

<= u>=C2=A0

=C2=A0

=C2=A0

Jim

=C2=A0

=C2=A0

--Cigdem= =C2=A0


Jim

_______________________________________________
Ace mailing li= st
Ace@ietf.orght= tps://www.ietf.org/mailman/listinfo/ace

<= /div>
--0000000000001fb474059c99bd57-- From nobody Tue Jan 21 10:23:24 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6651B12003F; Tue, 21 Jan 2020 10:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[AC_BR_BONANZA=0.001, BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vd-ozMKtLGyb; Tue, 21 Jan 2020 10:23:18 -0800 (PST) Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com [209.85.222.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9805412006F; Tue, 21 Jan 2020 10:23:17 -0800 (PST) Received: by mail-ua1-f43.google.com with SMTP id y23so1397347ual.2; Tue, 21 Jan 2020 10:23:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tXmlW+RjvYy7EwXees7Er9xTV4vMxd1oXTwk9HsP/xw=; b=dVbzKDoevxwXaxEp8vF+VTRnd3L4Sz9RkepxX7GSdCsubF0fjFxBC87WdUZ8itpqzK FsyVN69Pt/YJ2FktR74DKKHMTDiEw6VRMz8MUFARl2hi4PAnO3yuFRwTUKF+xc8qht2B JNaubT3FWhqQnGvhvU5hAUsIaCLUYx8bSHbPkzmhn9FRL3q3rR377aYKSSNSWKpDw9CU /Bg3l43DSGvwiF2Q+/+b6r0L4h54mQUBuaTGDHsw6zHR3ZYv1LZGAxJw+MODmK2C/jHV zbyKT/wBqHHqnkvL75fmUw57MfBCTWwqkwFqugBFrL2SsfsOlosuCVKMr/9RKLeMgnZ7 lGDA== X-Gm-Message-State: APjAAAVc9MPCgQrSb0kNwO5a/j2rFBLJIfNXjmF/2TV7MBmRB6rMzHr3 03h6i231AUJtpcYYZRNOilTgokf2iOJH8I6tYnM= X-Google-Smtp-Source: APXvYqwew6J5cYR84xxUnU4uPlNPoAiEp9g0AJNvl5YIB7X1H/B+jN8nd/5RSYMnV5VHo5BFDk8aUF8MaYQGJUdzC1s= X-Received: by 2002:ab0:74c8:: with SMTP id f8mr3566205uaq.114.1579630995895; Tue, 21 Jan 2020 10:23:15 -0800 (PST) MIME-Version: 1.0 References: <007401d5c0f3$6e80d320$4b827960$@augustcellars.com> <012301d5cda8$a5c74f00$f155ed00$@augustcellars.com> In-Reply-To: <012301d5cda8$a5c74f00$f155ed00$@augustcellars.com> From: Daniel Migault Date: Tue, 21 Jan 2020 13:23:04 -0500 Message-ID: To: Jim Schaad Cc: Cigdem Sengul , draft-ietf-ace-mqtt-tls-profile@ietf.org, Ace Wg Content-Type: multipart/alternative; boundary="00000000000062f872059caa80c2" Archived-At: Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-03 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 18:23:22 -0000 --00000000000062f872059caa80c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I reviewed the current version of the draft and please see my comments below. The quality of the document has improved a lot in my opinion. There are also some parts I need to review more in depth (including the security consideration). Yours, Daniel [...] 1. Introduction [...] In this document, topics, more specifically, Topic Names, are treated as resources. The Clients are assumed to have identified the publish/subscribe topics of interest out-of-band (topic discovery is not a feature of the MQTT protocol). A resource owner can pre- configure policies at the AS that give Clients publish or subscribe permissions to different topics. AS should be expanded. As we introduce the ACE terminology, it might be good to specify if "resource" terminology is used related to RS. I am not entirely sure... but if that is the case, it might be good to specify that these resources are hosted on a Resource Server. Though this is a very minor issue, there are multiple double spaces. Clients use an access token, bound to a proof-of-possession (PoP) key to authorize with the MQTT Broker their connection and publish/ subscribe permissions to topics. Though I am an not english native, I have difficulties to parse "to authorize with the MQTT Broker..." This is what I understand from the draft= : The permission to publish/suscbribe topics on a given MQTT Broker are defined by an access token, bound to a proof-of-possession (PoP) key. The token is provided by the AS and used by the Client's to access the RS. In the context of this ACE profile, the Broker acts as the Resource Server (RS). In the rest of the document the terms "RS" and "Broker" are used interchangeably. This document describes how to authoris= e the following exchanges between the Clients and the Broker. How to authorize... The wording sounds to me a bit strange though I would not pretend to have a better wording either, wouldn't associated permission more in line with the ACE framework ? o Connection requests from the Clients to the Broker o Publish requests from the Clients to the Broker, and from the Broker to the Clients o Subscribe requests from Clients to the Broker This document does not protect the contents of the PUBLISH message from the Broker, and hence, the content of the the PUBLISH message is the the Sengul, et al. Expires June 22, 2020 [Page 3] Internet-Draft MQTT-TLS profile of ACE December 2019 not signed or encrypted separately for the subscribers. This It is the first time the document mentions PUBLISH. It would worth maybe to specify it is an MQTT message. I am wondering if encrypted stands for the opposite of not signed. If so, a document may be signed but not encrypted. I also understand that the security is performed by TLS or similar mechanism. If that is correct, it might be clarifying to mention this is what we have in mind. It is also unclear why we introduce subscribers and not Clients. Are we excluding intentionally the publishers? Maybe wording around: the PUBLISH message is unprotected or protected via TLS (or equivalent mechanisms) for each Client's session. . What is unclear to me is what the "content" of the PUBLISH message represents. If that is the data associated to the topic. I would have expected authentication being performed by a signature mechanism and the signature being generated by the content owner, that is (I expect) the publisher. I think that data protection is out-of scope as well as MQTT based mechanisms as MQTT recommends TLS. functionality may be implemented using the proposal outlined in the CoAP Pub-Sub Profile [I-D.palombini-ace-coap-pubsub-profile]. To provide communication confidentiality and RS authentication, TLS is used and TLS 1.3 is RECOMMENDED. This document makes the same assumptions as the Section 4 of the ACE framework [I-D.ietf-ace-oauth-authz] regarding Client and RS registration with the AS and setting up keying material. Is registration appropriated for the RS to the AS? While the Client-Broker exchanges are only over MQTT, the required Client-AS and RS-AS interactions are described for HTTPS-based communication, using 'application/ace+json' content type, and unless otherwise specified, using JSON encoding. The token may be a reference, or JSON Web Token (JWT). For JWT tokens, this document follows RFC 7800 [RFC7800] for PoP semantics for JWTs. For my own understanding I would like to check if reference stands fo= r reference to an access token or something else. The Client-AS and RS-AS may also be other than HTTPS e.g., CoAP or MQTT. I suspect some words are missing. Maybe "may also use other transport protocol to carry the JWT.<.mglt> Implementations MAY also use 'application/ace+cbor' content type, and CBOR encoding, and CBOR Web Token (CWT) and associated PoP semantics to reduce the protocol memory and bandwidth requirements. For more information on Proof of Possession semantics for CWTs, see Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) [I-D.ietf-ace-cwt-proof-of-possession]. [...] 1.2. ACE-Related Terminology The terminology for entities in the architecture is defined in OAuth 2.0 RFC 6749 [RFC6749] such as "Client" (C), "Resource Server" (RS) and "Authorization Server" (AS). The term "Resource" is used to refer to an MQTT Topic Name, which is defined in Section 1.3. Hence, the "Resource Owner" is any entity that can authoritatively speak for the topic. The introduction is using "resource", I propose the introduction text is coherent with the Terminology used latter in the document. Certain security-related terms such as "authentication", "authorization", "confidentiality", "(data) integrity", "message authentication code", and "verify" are taken from RFC 4949 [RFC4949]. Sengul, et al. Expires June 22, 2020 [Page 4] Internet-Draft MQTT-TLS profile of ACE December 2019 1.3. MQTT-Related Terminology The document describes message exchanges as MQTT protocol interactions. The Clients are MQTT Clients, which connect to the Broker to publish and subscribe to Application Messages, labeled with their topics. For additional information, please refer to the MQTT v5.0 - the OASIS Standard [MQTT-OASIS-Standard-v5] or the MQTT v3.1.1 - the OASIS Standard [MQTT-OASIS-Standard]. MQTTS Secured transport profile of MQTT. MQTTS runs over TLS. I am wondering how appropriated it is to have sentence without verb. I probably think it is safer to use verb. Broker The Server in MQTT. It acts as an intermediary between the Clients that publishes Application Messages, and the Clients that made Subscriptions. The Broker acts as the Resource Server for the Clients. Similar comment as before, there seems to have a missing verb. While Broker is defined, Client is not defined as a special term but instead in the introduction of the section. I am wondering if that would not be cleaner to have Client also be defined. I am also wondering if Clients cannot be designated as subscriber/publisher. Note this is a question I am wondering, and I do not think a specific terminology would be needed. Instead, I would simply suggest, that Clients includes subscribers and publishers as these terms ar= e used later. Application Message The data carried by the MQTT protocol. The data has an associated QoS level and a Topic Name. QoS level The level of assurance for the delivery of an Application Message. The QoS level can be 0-2, where "0" indicates "At most once delivery", "1" "At least once delivery", and "2" "Exactly once delivery". Topic Name The label attached to an Application Message, which is matched to a Subscription. Subscription A subscription comprises a Topic Filter and a maximum Quality of Service (QoS). It might be relevant to specify that subscriptions are associated to one session. Topic Filter An expression that indicates interest in one or more Topic Names. Topic Filters may include wildcards. MQTT sends various control messages across a network connection. The following is not an exhaustive list and the control packets that are not relevant for authorization are not explained. These include, for instance, the PUBREL and PUBCOMP packets used in the 4-step handshake required for the QoS level 2. As a general comment, I would recommend to have the same definition a= s those provided by MQTTv5. We could clearly mention these are from MQTTv5 an= d are repeated here for the document to self contained. There is probably a balance to find to introduce terms that are not used in this document, so some definitions may be partial using [...]. This is mostly a suggestion. CONNECT Sengul, et al. Expires June 22, 2020 [Page 5] Internet-Draft MQTT-TLS profile of ACE December 2019 Client request to connect to the Broker. After a network connection is established, this is the first packet sent by a Client. I understand that network connection means the layers below MQTT. I thing this is confusing and would suggest to maybe remove "After a network connection is established," CONNACK The Broker connection acknowledgment. The first packet sent from the Broker to a Client is a CONNACK packet. CONNACK packets contain return codes indicating either a success or an error state to a Client. AUTH Authentication Exchange. An AUTH packet is sent from the Client to the Broker or to the Broker to the Client as part of an extended authentication exchange. AUTH Properties include Authentication Method and Authentication Data. The Authentication Method is set in the CONNECT packet, and consequent AUTH packets follow the same Authentication Method. The contents of the Authentication Data are defined by the Authentication Method. PUBLISH Publish request sent from a publishing Client to the Broker, or from the Broker to a subscribing Client. PUBACK Response to PUBLISH request with QoS level 1. PUBACK can be sent from the Broker to a Client or a Client to the Broker. PUBREC Response to PUBLISH request with QoS level 2. PUBREC can be sent from the Broker to a Client or a Client to the Broker. SUBSCRIBE The Client subscribe request. I would suggest to have similar wording for PUBLISH as for SUBSCRIBE. SUBACK Subscribe acknowledgment. PINGREQ A ping request sent from a Client to the Broker. It signals to the Broker that the Client is alive, and is used to confirm that the Broker is also alive. The "Keep Alive" period is set in the CONNECT message. PINGRESP Response sent by the Broker to the Client in response to PINGREQ. It indicates the Broker is alive. Sengul, et al. Expires June 22, 2020 [Page 6] Internet-Draft MQTT-TLS profile of ACE December 2019 Will If the network connection is not closed normally, the Server sends a last Will message for the Client, if the Client provided one in its CONNECT message. If the Will Flag is set, then the payload of the CONNECT message includes information about the Will. The information consists of the Will Properties, Will Topic, and Will Payload fields. 2. Authorizing Connection Requests This section specifies how Client connections are authorized by the MQTT Broker.Figure 1 shows the basic protocol flow during connection set-up.The token request and response use the /token endpoint at the I suspect "/" should not be here and that url path is not intended. [...] 2.2.1. Client-Server Authentication over TLS and MQTT The Client and the Broker MUST perform mutual authentication. If I am correct this is also correct for the C-AS. The Client MAY authenticate to the Broker over MQTT or TLS. My understanding of the sentence above is that the Client MAY authenticate. Unless I am missing something, I would rather see MUST instead. For MQTT, the options are "None" and "ace". For TLS, the options are "Anon" for anonynous client, and "Known(RPK/PSK)" for Raw Public Keys (RPK) and Pre-Shared Keys (PSK), respectively. Combined, the Client authentication takes the following options: o "TLS:Anon-MQTT:None": This option is used only for the topics that do not require authorization, including the "authz-info" topic. Publishing to the "authz-info" topic is described in Section 2.2.2. It is a bit unseal to describe unauthenticated channel as mutually authenticated. o "TLS:Anon-MQTT:ace": The token is transported inside the CONNECT message, and MUST be validated using one of the methods described in Section 2.2.2. This option also supports a tokenless connection request for AS discovery. o "TLS:Known(RPK/PSK)-MQTT:none": For the RPK, the token MUST have been published to the "authz-info" topic. For the PSK, the token MAY be, alternatively, provided in the "psk_identity". The TLS session set-up is as described in DTLS profile for ACE [I-D.ietf-ace-dtls-authorize]. Just to me sure I understand it properly. In this case the RPK or PSK is the one contained into the token. DTLS authenticate the TLS client via a CertificateRequest. Other information related to the topic are performed by the MQTT. In order to perform perform the TLS authentication, the token with th= e existing key needs to be found. The Broker upon receiving a CONNECT needs t= o keep track of the used token. o "TLS:Known(RPK/PSK)-MQTT:ace": This option SHOULD NOT be chosen. In any case, the token transported in the CONNECT overwrites any permissions passed during the TLS authentication. My understanding is that the same access token would be used. Collision would occurs when different access token would be used. However, when authentication is performed using DTLS, the Broker, as I would understand it, keeps track of the used token, which should avoid the overwriting rules. It is RECOMMENDED that the Client follows TLS:Anon-MQTT:ace. The Broker MUST be authenticated during the TLS handshake. If the Client authentication uses TLS:Known(RPK/PSK), then the Broker is authenticated using the respective method. I understand that when the server is authenticated using RPK, the server needs to be authenticated using RPK, but it is unclear why standard WPKI would not work. I understand that for PSK the same method can be used, though. Otherwise, to authenticate the Broker, the client MUST validate a public key from a X.509 certificate or an RPK from the Broker against the 'rs_cnf' parameter in the token response. The AS MAY include the thumbprint Sengul, et al. Expires June 22, 2020 [Page 9] Internet-Draft MQTT-TLS profile of ACE December 2019 of the RS's X.509 certificate in the 'rs_cnf' (thumbrint as defined in [I-D.ietf-cose-x509]), then the client MUST validate the RS certificate against this thumbprint. 2.2.2. authz-info: The Authorization Information Topic In the cases when the Client MUST transport the token to the Broker before the TLS handshake, the Client connects to the Broker and publishes its token to the "authz-info" topic. The "authz-info" topic MUST be publish-only (i.e., the Clients are not allowed to subscribe to it). "authz-info" is not protected, and hence, the Client authenticates with the RS using the "TLS:Anon-MQTT:None" option. After publishing the token, the Client disconnects from the Broker and is expected to try reconnecting over TLS. The Broker stores and indexes all tokens received to this topic in its key store similar to DTLS profile for ACE [I-D.ietf-ace-dtls-authorize]. This profile follows the recommendation of Section 5.8.1 of ACE framework [I-D.ietf-ace-oauth-authz], and expects that RS stores only one token per proof-of-possession key, and any other token linked to the same key overwrites existing token at the RS. I think the intend is to avoid having multiple access token that coul= d have the same PoP with different permissions. Keeping only the latest does not guarantee the client and the broker are considering the same ticket, and MA= Y force client to perform a two step authentication at any time. In case of rekey or synchronization issues, this might generate more traffic than needed. I would think that keeping track of the access token used by DTLS is safer, the way described here is only one way of doing it. [...] 2.2.4.1. Proof-of-Possession Using a Challenge from the TLS session For this option, the Authentication Data MUST contain the token and the keyed message digest (MAC) or the Client signature. The secret that is used for the proof-of-possession calculation, i.e., to calculate the keyed message digest (MAC) or the Client signature, is obtained using a TLS exporter ([RFC5705] for TLS 1.2 and for TLS 1.3, Section 7.5 of [RFC8446]). Just to make sure I follow, the secret is signed or MACed without being sent. The secret is not used to derive the key used to the signature or MAC= . Instead this key is in the access token. If I am correct, the use of MAC o= r signature is defined by the PoP symmetric or asymmetric. Correct ? I believ= e the text could be clearer. The secret is exported from TLS using the exporter label 'EXPORTER-ACE-Sign-Challenge', an empty context, and length of 32 bytes. The token is also validated as described in Section 2.2.5 and the server responds with a CONNACK with the appropriate response code. 2.2.4.2. Proof-of-Possession via Broker-generated Challenge/Response For this option, the RS follows a Broker-generated challenge/response protocol. The success case is illustrated in Figure 4. If the Authentication Data only includes the token, the RS MUST respond with an AUTH packet, with the Authenticate Reason Code set to '0x18 (Continue Authentication)'. This packet includes the Authentication Method, which MUST be set to 'ace' and Authentication Data. The Authentication Data MUST NOT be empty and contains an 8-byte nonce as a challenge for the Client. The Client responds to this with an AUTH packet with a reason code '0x18 (Continue Authentication)'. Similarly, the Client packet sets the Authentication Method to 'ace'. The Authentication Data in the Client's response contains a client- generated 8-byte nonce, and the signature or MAC computed over the RS nonce concatenated with the client nonce. Next, the token is validated as described in Section 2.2.5. I do not see exporters being involved, and if that is correct there is no channel binding. As DTLS is mandatory, wouldn't it be possible to add the exporter to the nonces. This may also be used to increases the randomness o= f the nonces [...] 3.1. PUBLISH Messages from the Publisher Client to the Broker On receiving the PUBLISH message, the Broker MUST use the type of message (i.e., PUBLISH) and the Topic name in the message header to match against the scope string in the cached token or its introspection result. Following the example above, a client sending a PUBLISH message to 'a/topic3' would be allowed to publish, as the scope includes the string 'publish_+/topic3'. If the Client is allowed to publish to the topic, the RS must publish While "must" may not be necessary, if used, it could be normative. the message to all valid subscribers of the topic. In the case of an authorization failure, an error MAY be returned to the Client. For this the QoS level of the PUBLISH message MUST be set to greater than or equal to 1. This guarantees that RS responds with either a PUBACK or PUBREC packet with reason code '0x87 (Not authorized)'. On receiving a PUBACK with '0x87 (Not authorized)', the Client MAY reauthenticate as described in Section 4, and pass a new token following the same PoP methods as described in Figure 2. 3.2. PUBLISH Messages from the Broker to the Subscriber Clients To forward PUBLISH messages to the subscribing Clients, the Broker identifies all the subscribers that have valid matching topic subscriptions (i.e., the tokens are valid, and token scopes allow a subscription to the particular topic). The Broker sends a PUBLISH message with the Topic name to all the valid subscribers. RS MUST stop forwarding messages to the unauthorized subscribers. I do not think they should have started. I am wondering if s/stop/NOT= / would not be better. There is no way to inform the Clients with invalid tokens that an authorization error has occurred other than sending a DISCONNECT message. The RS SHOULD send a DISCONNECT message with the reason code '0x87 (Not authorized)'. Note that the server-side DISCONNECT is a new feature of MQTT v5.0 (in MQTT v3.1.1, the server needs to drop the connection). [...] 4. Token Expiration and Reauthentication The Broker MUST check for token expiration whenever a CONNECT, PUBLISH or SUBSCRIBE message is received or sent. The Broker SHOULD check for token expiration on receiving a PINGREQUEST message. The Broker MAY also check for token expiration periodically e.g., every hour. This may allow for early detection of a token expiry. The token expiration is checked by checking the 'exp' claim of a JWT or introspection response, or via performing an introspection request with the AS as described in Section 5.7 of the ACE framework [I-D.ietf-ace-oauth-authz]. Token expirations may trigger the RS to send PUBACK, SUBACK and DISCONNECT messages with return code set to 'Not authorised'. After sending a DISCONNECT message, the network connection is closed, and no more messages can be sent. However, as a response to the PUBACK and SUBACK, the Client MAY re-authenticate by sending an AUTH packet with a Reason Code of '0x19 (Re- authentication)'. To re-authenticate, the Client sends an AUTH packet with reason code '0x19 (Re-authentication)'. The Client MUST set the Authentication Method as 'ace' and transport the new token in the Authentication Data. The Client and the RS go through the same steps for proof of possession validation as described in Section 2.2. The Client SHOULD use the same method used for the first connection request. I am wondering if there are good reasons for SHOULD. I would say that using multiple authentication method with different level of trust SHOULD b= e avoided. Sengul, et al. Expires June 22, 2020 [Page 27] On Fri, Jan 17, 2020 at 9:40 PM Jim Schaad wrote: > > > > > *From:* Cigdem Sengul > *Sent:* Tuesday, January 14, 2020 8:25 AM > *To:* Jim Schaad > *Cc:* draft-ietf-ace-mqtt-tls-profile@ietf.org; Ace Wg > *Subject:* Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-03 > > > > Thank you for this review, Jim. > > Responses inline. > > > > On Wed, Jan 1, 2020 at 10:33 PM Jim Schaad wrote= : > > > > > 2.2.2 - I am unclear under what circumstances you could end put with a > token > which does not parse when processing a PUBLISH message. If the token > cannot > be parsed at connection time, that I can understand. However having pars= ed > the token then it does not make sense that the token becomes not parsable > at > the time of publishing. Am I missing something? > > > > [CS] There is a misunderstanding. The PUBLISH message refers to the actua= l > PUBLISH message to the "authz-info" topic which contains the token i.e., > this may not parse to a token. (The PUBLISH message is not for other > messages that are permissioned in the token.) > > The client connects (without much security), publishes the token to the > public "authz-info" topic, which only the broker can read. > > Then, disconnects, and tries to connect with ace security. > > > > Since MQTT v5 can return error messages in response to PUBLISH messages, > here, this is used to signal to the publisher that there is something wro= ng > with its token. > > > > Added: https://github.com/ace-wg/mqtt-tls-profile/issues/38 > > > > [JLS] Ok =E2=80=93 I see where I got mixed in in reading this. I think t= his may > just be a problem on my end and you might not be able to do this better. > > > > > > > > > 2.2.4 - I am having a problem with trying to parse the content of the AUT= H > property. I have no problems with 2.2.4.3 because this is a zero length > sequence of bytes. However for 2.2.4.1 and 2.2.4.2 there is a token > (possibly binary with no length prefix) followed by an optional binary > cryptographic value. For introspection, I would need to figure out the > length of the token before I could make a guess at the length of the > cryptographic value. However given that there is no divider this does no= t > seem possible. This may also become a problem for the response from the > client in the event that there is a change from an 8-byte nonce to a > variable length one. > > > > [CS] Not specified a format, because I thought we discarded the idea of > using the variable-length nonce based on the meeting in Singapore. > > What would you suggest - introduce a specific format to accommodate > variable length? > > length_of_token+binary data for token+(the rest is cryptographic value)? > > https://github.com/ace-wg/mqtt-tls-profile/issues/40 > > > > [JLS] I put in a comment on the github issue about what I was looking > for. Additionally, my only possible problem with the fixed size nonce i= s > that the IESG or Security Directorate down the line may decide that it is > too small for some reason (16 bytes signed by a 521-bit (65+ byte key)). > Some might consider it to be small for a SHA-256 MAC operation. Not the > exact same situation here for TLS as it is not really a compact protocol. > But it may considered to be for the IoT variants being used. I don=E2=80= =99t know. > > > > > > Jim > > > > > I am going to play with something else. I am sure I will find other issu= es > at a different time. > > > > Thank you for your review. Much appreciated. > > --Cigdem > > > > > Jim > > > > > > > > > > > > > > > Nits: > Section 2 Para 1 s/Broker.Figure 1/Broker. Figure 1/ > Section 2 Para 1 s/setup.The/setup. The/ > Section 2.2.2 Last Para s/when the AS/when the RS/ > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --00000000000062f872059caa80c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

I reviewed the current versio= n of the draft and please see my comments below. The quality of the documen= t has improved a lot in my opinion. There are also some parts I need to rev= iew more in depth (including the security=C2=A0consideration).=C2=A0
<= div>
Yours,=C2=A0
Daniel

[= ...]

1.=C2=A0 Introduction

[...]

=C2=A0 =C2=A0In this = document, topics, more specifically, Topic Names, are treated
=C2=A0 =C2= =A0as resources.=C2=A0 The Clients are assumed to have identified the
= =C2=A0 =C2=A0publish/subscribe topics of interest out-of-band (topic discov= ery is
=C2=A0 =C2=A0not a feature of the MQTT protocol).=C2=A0 A resourc= e owner can pre-
=C2=A0 =C2=A0configure policies at the AS that give Cli= ents publish or subscribe
=C2=A0 =C2=A0permissions to different topics.<= br>
<mglt> AS should be expanded. As we introduce the ACE terminol= ogy, it might be
good to specify if "resource" terminology is = used related to RS. I am not
entirely sure... but if that is the case, i= t might be good to specify that
these resources are hosted on a Resource= Server.

Though this is a very minor issue, there are multiple doub= le spaces.</mglt>
=C2=A0
=C2=A0 =C2=A0Clients use an access tok= en, bound to a proof-of-possession (PoP) key to
authorize with the MQTT = Broker their connection and publish/ subscribe
permissions to topics.
<mglt>Though I am an not english native, I have difficulties to= parse "to
authorize with the MQTT Broker..." This is what I u= nderstand from the draft:
The permission to publish/suscbribe topics on = a given MQTT Broker are defined
by an =C2=A0access token, bound to a pro= of-of-possession (PoP) key. The token is
provided by the AS and used by = the Client's to access the RS. </mglt>

=C2=A0In the contex= t of this ACE profile, the Broker acts as
the Resource Server (RS).=C2= =A0 In the rest of the document the terms "RS" and
"Broke= r" are used interchangeably.=C2=A0 This document describes how to auth= orise
the following exchanges between the Clients and the Broker.
<mglt>How to authorize... The wording sounds to me a bit strange tho= ugh I would
not pretend to have a better wording either, wouldn't as= sociated permission
more in line with the ACE framework ?</mglt>
=C2=A0 =C2=A0o =C2=A0Connection requests from the Clients to the Brok= er

=C2=A0 =C2=A0o =C2=A0Publish requests from the Clients to the Bro= ker, and from the
=C2=A0 =C2=A0 =C2=A0 Broker to the Clients

=C2= =A0 =C2=A0o =C2=A0Subscribe requests from Clients to the Broker

=C2= =A0 =C2=A0This document does not protect the contents of the PUBLISH messag= e
=C2=A0 =C2=A0from the Broker, and hence, the content of the the PUBLIS= H message is

<mglt>the the</mglt>


Sengul, et = al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires June 22, 2020 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 3]
=0C
Interne= t-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MQTT-TLS profile of ACE =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 December 2019


=C2=A0 =C2=A0not signe= d or encrypted separately for the subscribers.=C2=A0 This

<mglt&g= t;
It is the first time the document mentions PUBLISH. It would worth m= aybe to
specify it is an MQTT message.

I am wondering if encrypt= ed stands for the opposite of not signed. If so, a
document may be signe= d but not encrypted.=C2=A0 I also understand that the security
is perfor= med by TLS or similar mechanism. If that is correct, it might be
clarify= ing to mention this is what we have in mind.=C2=A0 It is also unclear why w= e
introduce subscribers and not Clients. Are we excluding intentionally = the
publishers?
=C2=A0
Maybe wording around: the PUBLISH message i= s unprotected or protected
via TLS (or equivalent mechanisms) for each C= lient's session. . =C2=A0

What is unclear to me is what the &quo= t;content" of the PUBLISH message represents.
If that is the data a= ssociated to the topic. I would have expected
authentication being perfo= rmed by a signature mechanism and the signature being
generated by the c= ontent owner, that is (I expect) the publisher. I think that
data protec= tion is out-of scope as well as MQTT based mechanisms as MQTT
recommends= TLS.

</mglt>


=C2=A0 =C2=A0functionality may be im= plemented using the proposal outlined in the
=C2=A0 =C2=A0CoAP Pub-Sub P= rofile [I-D.palombini-ace-coap-pubsub-profile].


=C2=A0 =C2=A0To = provide communication confidentiality and RS authentication, TLS
=C2=A0 = =C2=A0is used and TLS 1.3 is RECOMMENDED.=C2=A0 This document makes the sam= e
=C2=A0 =C2=A0assumptions as the Section 4 of the ACE framework
=C2= =A0 =C2=A0[I-D.ietf-ace-oauth-authz] regarding Client and RS registration w= ith
=C2=A0 =C2=A0the AS and setting up keying material.

<mglt= > Is registration appropriated for the RS to the AS? </mglt>
=C2=A0 =C2=A0While the Client-Broker
=C2=A0 =C2=A0exchanges are only o= ver MQTT, the required Client-AS and RS-AS
=C2=A0 =C2=A0interactions are= described for HTTPS-based communication, using
=C2=A0 =C2=A0'applic= ation/ace+json' content type, and unless otherwise specified,
=C2=A0= =C2=A0using JSON encoding.=C2=A0 The token may be a reference, or JSON Web= Token
=C2=A0 =C2=A0(JWT).=C2=A0 For JWT tokens, this document follows R= FC 7800 [RFC7800] for
=C2=A0 =C2=A0PoP semantics for JWTs.

<m= glt>For my own understanding I would like to check if reference stands f= or
reference to an access token or something else. =C2=A0 </mglt><= br>
=C2=A0The Client-AS and RS-AS may also be other
=C2=A0 =C2=A0than= HTTPS e.g., CoAP or MQTT. =C2=A0

<mglt>I suspect some words a= re missing. Maybe "may also use other transport
protocol to carry t= he JWT.<.mglt>

Implementations MAY also use
=C2=A0 =C2=A0&#= 39;application/ace+cbor' content type, and CBOR encoding, and CBOR Web<= br>=C2=A0 =C2=A0Token (CWT) and associated PoP semantics to reduce the prot= ocol
=C2=A0 =C2=A0memory and bandwidth requirements.=C2=A0 For more info= rmation on Proof of
=C2=A0 =C2=A0Possession semantics for CWTs, see Proo= f-of-Possession Key Semantics
=C2=A0 =C2=A0for CBOR Web Tokens (CWTs) [I= -D.ietf-ace-cwt-proof-of-possession].

[...]

1.2.=C2=A0 ACE-Re= lated Terminology

=C2=A0 =C2=A0The terminology for entities in the a= rchitecture is defined in OAuth
=C2=A0 =C2=A02.0 RFC 6749 [RFC6749] such= as "Client" (C), "Resource Server" (RS)
=C2=A0 =C2= =A0and "Authorization Server" (AS).

=C2=A0 =C2=A0The term = "Resource" is used to refer to an MQTT Topic Name, which is
= =C2=A0 =C2=A0defined in Section 1.3.=C2=A0 Hence, the "Resource Owner&= quot; is any entity
=C2=A0 =C2=A0that can authoritatively speak for the = topic.

<mglt>The introduction is using "resource", I= propose the introduction text is
coherent with the Terminology used lat= ter in the document. </mglt>

=C2=A0 =C2=A0Certain security-re= lated terms such as "authentication",
=C2=A0 =C2=A0"autho= rization", "confidentiality", "(data) integrity", = "message
=C2=A0 =C2=A0authentication code", and "verify&q= uot; are taken from RFC 4949 [RFC4949].








= Sengul, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires June 22, 20= 20 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 4]
=0C<= br>Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MQTT-TLS profile of AC= E =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 December 2019


1.3.=C2=A0 MQ= TT-Related Terminology

=C2=A0 =C2=A0The document describes message e= xchanges as MQTT protocol
=C2=A0 =C2=A0interactions.=C2=A0 The Clients a= re MQTT Clients, which connect to the
=C2=A0 =C2=A0Broker to publish and= subscribe to Application Messages, labeled with
=C2=A0 =C2=A0their topi= cs.=C2=A0 For additional information, please refer to the MQTT
=C2=A0 = =C2=A0v5.0 - the OASIS Standard [MQTT-OASIS-Standard-v5] or the MQTT v3.1.1=
=C2=A0 =C2=A0- the OASIS Standard [MQTT-OASIS-Standard].

=C2=A0 = =C2=A0MQTTS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Secured transport p= rofile of MQTT.=C2=A0 MQTTS runs over TLS.

<mglt> I am wonderi= ng how appropriated it is to have sentence without verb. I
probably thin= k it is safer to use verb.</mglt>

=C2=A0 =C2=A0Broker
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The Server in MQTT.=C2=A0 It acts as = an intermediary between the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Cli= ents that publishes Application Messages, and the Clients
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0that made Subscriptions.=C2=A0 The Broker acts a= s the Resource
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Server for the C= lients.

<mglt>Similar comment as before, there seems to have a= missing verb.=C2=A0 While
Broker is defined, Client is not defined as a= special term but instead in the
introduction of the section. I am wonde= ring if that would not be cleaner to
have Client also be defined. I am a= lso wondering if Clients cannot be
designated as subscriber/publisher. N= ote this is a question I am wondering, and
I do not think a specific ter= minology would be needed. Instead, I would simply
suggest, that Clients = includes subscribers and publishers as these terms are
used later. =C2= =A0</mglt>

=C2=A0 =C2=A0Application Message
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0The data carried by the MQTT protocol.=C2=A0 The= data has an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0associated QoS lev= el and a Topic Name.

=C2=A0 =C2=A0QoS level
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0The level of assurance for the delivery of an Applicati= on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Message.=C2=A0 The QoS level= can be 0-2, where "0" indicates "At
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0most once delivery", "1" "At least= once delivery", and "2"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0"Exactly once delivery".

=C2=A0 =C2=A0Topic Name=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The label attached to an Appli= cation Message, which is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0matche= d to a Subscription.

=C2=A0 =C2=A0Subscription
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0A subscription comprises a Topic Filter and a maxim= um Quality
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of Service (QoS).
<mglt>It might be relevant to specify that subscriptions are ass= ociated to one
session. =C2=A0</mglt>

=C2=A0 =C2=A0Topic Fi= lter
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0An expression that indicat= es interest in one or more Topic
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Names.=C2=A0 Topic Filters may include wildcards.

=C2=A0 =C2=A0MQ= TT sends various control messages across a network connection.=C2=A0 The=C2=A0 =C2=A0following is not an exhaustive list and the control packets t= hat are
=C2=A0 =C2=A0not relevant for authorization are not explained.= =C2=A0 These include, for
=C2=A0 =C2=A0instance, the PUBREL and PUBCOMP = packets used in the 4-step handshake
=C2=A0 =C2=A0required for the QoS l= evel 2.

<mglt>As a general comment, I would recommend to have = the same definition as
those provided by MQTTv5. We could clearly mentio= n these are from MQTTv5 and
are repeated here for the document to self c= ontained. There is probably a
balance to find to introduce terms that ar= e not used in this document, so some
definitions may be partial using [.= ..]. This is mostly a suggestion. </mglt>

=C2=A0
=C2=A0 =C2= =A0CONNECT




Sengul, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Expires June 22, 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 [Page 5]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 MQTT-TLS profile of ACE =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 De= cember 2019


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Client requ= est to connect to the Broker.=C2=A0 After a network
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0connection is established, this is the first packet se= nt by a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Client.

<mglt= >I understand that network connection means the layers below MQTT. I thi= ng
this is confusing and would suggest to maybe remove "After a net= work connection
is established,"</mglt>

=C2=A0 =C2=A0C= ONNACK
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The Broker connection ac= knowledgment.=C2=A0 The first packet sent
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0from the Broker to a Client is a CONNACK packet.=C2=A0 CONNACK=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0packets contain return codes i= ndicating either a success or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a= n error state to a Client.

=C2=A0 =C2=A0AUTH
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0Authentication Exchange.=C2=A0 An AUTH packet is sent = from the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Client to the Broker o= r to the Broker to the Client as part
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0of an extended authentication exchange.=C2=A0 AUTH Properties
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0include Authentication Method and Aut= hentication Data.=C2=A0 The
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Aut= hentication Method is set in the CONNECT packet, and
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0consequent AUTH packets follow the same Authenticat= ion
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Method.=C2=A0 The contents = of the Authentication Data are defined
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0by the Authentication Method.

=C2=A0 =C2=A0PUBLISH
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Publish request sent from a publishin= g Client to the Broker,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0or from= the Broker to a subscribing Client.

=C2=A0 =C2=A0PUBACK
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Response to PUBLISH request with QoS leve= l 1.=C2=A0 PUBACK can be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sent f= rom the Broker to a Client or a Client to the Broker.

=C2=A0 =C2=A0P= UBREC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Response to PUBLISH reque= st with QoS level 2.=C2=A0 PUBREC can be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0sent from the Broker to a Client or a Client to the Broker.
=C2=A0 =C2=A0SUBSCRIBE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The Cl= ient subscribe request.

<mglt>I would suggest to have similar = wording for PUBLISH as for
SUBSCRIBE.</mglt>

=C2=A0 =C2=A0S= UBACK
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Subscribe acknowledgment.=

=C2=A0 =C2=A0PINGREQ
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A = ping request sent from a Client to the Broker.=C2=A0 It signals
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to the Broker that the Client is alive, a= nd is used to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0confirm that the = Broker is also alive.=C2=A0 The "Keep Alive"
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0period is set in the CONNECT message.

=C2=A0= =C2=A0PINGRESP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Response sent b= y the Broker to the Client in response to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0PINGREQ.=C2=A0 It indicates the Broker is alive.



Sengul, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires June = 22, 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 6]=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MQTT-TLS profile= of ACE =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 December 2019


=C2=A0 = =C2=A0Will
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If the network conne= ction is not closed normally, the Server
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0sends a last Will message for the Client, if the Client
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0provided one in its CONNECT message.=C2= =A0 If the Will Flag is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0set, th= en the payload of the CONNECT message includes
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0information about the Will.=C2=A0 The information consists= of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Will Properties, Will T= opic, and Will Payload fields.

2.=C2=A0 Authorizing Connection Reque= sts

=C2=A0 =C2=A0This section specifies how Client connections are a= uthorized by the
=C2=A0 =C2=A0MQTT Broker.Figure 1 shows the basic proto= col flow during connection
=C2=A0 =C2=A0set-up.The token request and res= ponse use the /token endpoint at the

<mglt> I suspect "/&= quot; should not be here and that url path is not
intended.</mglt>=

[...]

2.2.1.=C2=A0 Client-Server Authentication over TLS and= MQTT

=C2=A0 =C2=A0The Client and the Broker MUST perform mutual aut= hentication. =C2=A0

<mglt>If I am correct this is also correct= for the C-AS.</mglt>

=C2=A0The
=C2=A0 =C2=A0Client MAY aut= henticate to the Broker over MQTT or TLS.

<mglt>My understand= ing of the sentence above is that the Client MAY
authenticate. Unless I = am missing something, I would rather see MUST
instead.</mglt>
<= br>=C2=A0 =C2=A0For MQTT,
=C2=A0 =C2=A0the options are "None" = and "ace".=C2=A0 For TLS, the options are "Anon"
=C2= =A0 =C2=A0for anonynous client, and "Known(RPK/PSK)" for Raw Publ= ic Keys (RPK)
=C2=A0 =C2=A0and Pre-Shared Keys (PSK), respectively.=C2= =A0 Combined, the Client
=C2=A0 =C2=A0authentication takes the following= options:

=C2=A0 =C2=A0o =C2=A0"TLS:Anon-MQTT:None": This = option is used only for the topics that
=C2=A0 =C2=A0 =C2=A0 do not requ= ire authorization, including the "authz-info" topic.
=C2=A0 = =C2=A0 =C2=A0 Publishing to the "authz-info" topic is described i= n
=C2=A0 =C2=A0 =C2=A0 Section 2.2.2.

<mglt>It is a bit uns= eal to describe unauthenticated channel as mutually
authenticated.</m= glt>
=C2=A0
=C2=A0 =C2=A0o =C2=A0"TLS:Anon-MQTT:ace": Th= e token is transported inside the CONNECT message,
and MUST be validated= using one of the methods described in Section 2.2.2.
This option also s= upports a tokenless connection request for AS discovery.

=C2=A0 =C2= =A0o =C2=A0"TLS:Known(RPK/PSK)-MQTT:none": For the RPK, the token= MUST have
=C2=A0 =C2=A0 =C2=A0 been published to the "authz-info&q= uot; topic.=C2=A0 For the PSK, the token
=C2=A0 =C2=A0 =C2=A0 MAY be, al= ternatively, provided in the "psk_identity".=C2=A0 The TLS
=C2= =A0 =C2=A0 =C2=A0 session set-up is as described in DTLS profile for ACE=C2=A0 =C2=A0 =C2=A0 [I-D.ietf-ace-dtls-authorize].

<mglt> Ju= st to me sure I understand it properly. In this case the RPK or PSK is
t= he one contained into the token. DTLS authenticate the TLS client via a
= CertificateRequest. Other information related to the topic are performed by= the
MQTT. In order to perform perform the TLS authentication, the token= with the
existing key needs to be found. The Broker upon receiving a CO= NNECT needs to
keep track of the used token. =C2=A0</mglt>

= =C2=A0 =C2=A0o =C2=A0"TLS:Known(RPK/PSK)-MQTT:ace": This option S= HOULD NOT be chosen.
=C2=A0 =C2=A0 =C2=A0 In any case, the token transpo= rted in the CONNECT overwrites any
=C2=A0 =C2=A0 =C2=A0 permissions pass= ed during the TLS authentication.

<mglt>My understanding is th= at the same access token would be used. Collision
would occurs when diff= erent access token would be used. However, when
authentication is perfor= med using DTLS, the Broker, as I would understand it,
keeps track of the= used token, which should avoid the overwriting rules.</mglt>

= =C2=A0 =C2=A0It is RECOMMENDED that the Client follows TLS:Anon-MQTT:ace.
=C2=A0 =C2=A0The Broker MUST be authenticated during the TLS handshak= e.=C2=A0 If the
=C2=A0 =C2=A0Client authentication uses TLS:Known(RPK/PS= K), then the Broker is
=C2=A0 =C2=A0authenticated using the respective m= ethod.

<mglt>I understand that when the server is authenticate= d using RPK, the server
needs to be authenticated using RPK, but it is u= nclear why standard WPKI would
not work. I understand that for PSK the s= ame method can be used, though.
</mglt>

=C2=A0 Otherwise, t= o
=C2=A0 =C2=A0authenticate the Broker, the client MUST validate a publi= c key from a
=C2=A0 =C2=A0X.509 certificate or an RPK from the Broker ag= ainst the 'rs_cnf'
=C2=A0 =C2=A0parameter in the token response.= =C2=A0 The AS MAY include the thumbprint



Sengul, et al. =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires June 22, 2020 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 9]
=0C
Internet-Draft= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MQTT-TLS profile of ACE =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 December 2019


=C2=A0 =C2=A0of the RS's = X.509 certificate in the 'rs_cnf' (thumbrint as defined
=C2=A0 = =C2=A0in [I-D.ietf-cose-x509]), then the client MUST validate the RS
=C2= =A0 =C2=A0certificate against this thumbprint.

2.2.2. =C2=A0authz-in= fo: The Authorization Information Topic

=C2=A0 =C2=A0In the cases wh= en the Client MUST transport the token to the Broker
=C2=A0 =C2=A0before= the TLS handshake, the Client connects to the Broker and
=C2=A0 =C2=A0p= ublishes its token to the "authz-info" topic.=C2=A0 The "aut= hz-info"
=C2=A0 =C2=A0topic MUST be publish-only (i.e., the Clients= are not allowed to
=C2=A0 =C2=A0subscribe to it). =C2=A0"authz-inf= o" is not protected, and hence, the
=C2=A0 =C2=A0Client authenticat= es with the RS using the "TLS:Anon-MQTT:None"
=C2=A0 =C2=A0opt= ion.=C2=A0 After publishing the token, the Client disconnects from the
= =C2=A0 =C2=A0Broker and is expected to try reconnecting over TLS.

= =C2=A0 =C2=A0The Broker stores and indexes all tokens received to this topi= c in
=C2=A0 =C2=A0its key store similar to DTLS profile for ACE
=C2= =A0 =C2=A0[I-D.ietf-ace-dtls-authorize].=C2=A0 This profile follows the
= =C2=A0 =C2=A0recommendation of Section 5.8.1 of ACE framework
=C2=A0 =C2= =A0[I-D.ietf-ace-oauth-authz], and expects that RS stores only one token=C2=A0 =C2=A0per proof-of-possession key, and any other token linked to th= e same
=C2=A0 =C2=A0key overwrites existing token at the RS.

<= mglt>I think the intend is to avoid having multiple access token that co= uld
have the same PoP with different permissions. Keeping only the lates= t does not
guarantee the client and the broker are considering the same = ticket, and MAY
force client to perform a two step authentication at any= time. In case of rekey
or synchronization issues, this might generate m= ore traffic than needed. I
would think that keeping track of the access = token used by DTLS is safer, the
way described here is only one way of d= oing it. </mglt>

[...]

2.2.4.1.=C2=A0 Proof-of-Possess= ion Using a Challenge from the TLS session

=C2=A0 =C2=A0For this opt= ion, the Authentication Data MUST contain the token and
=C2=A0 =C2=A0the= keyed message digest (MAC) or the Client signature.=C2=A0 The secret
= =C2=A0 =C2=A0that is used for the proof-of-possession calculation, i.e., to=
=C2=A0 =C2=A0calculate the keyed message digest (MAC) or the Client sig= nature, is
=C2=A0 =C2=A0obtained using a TLS exporter ([RFC5705] for TLS= 1.2 and for TLS 1.3,
=C2=A0 =C2=A0Section 7.5 of [RFC8446]).

&l= t;mglt>Just to make sure I follow, the secret is signed or MACed without= being
sent. The secret is not used to derive the key used to the signat= ure or MAC.
Instead this key is in the access token.=C2=A0 If I am corre= ct, the use of MAC or
signature is defined by the PoP symmetric or asymm= etric. Correct ? I believe
the text could be clearer. =C2=A0</mglt>= ;

=C2=A0 The secret is exported from TLS using the
=C2=A0 =C2=A0e= xporter label 'EXPORTER-ACE-Sign-Challenge', an empty context, and<= br>=C2=A0 =C2=A0length of 32 bytes.=C2=A0 The token is also validated as de= scribed in
=C2=A0 =C2=A0Section 2.2.5 and the server responds with a CON= NACK with the
=C2=A0 =C2=A0appropriate response code.

2.2.4.2.=C2= =A0 Proof-of-Possession via Broker-generated Challenge/Response

=C2= =A0 =C2=A0For this option, the RS follows a Broker-generated challenge/resp= onse
=C2=A0 =C2=A0protocol.=C2=A0 The success case is illustrated in Fig= ure 4.=C2=A0 If the
=C2=A0 =C2=A0Authentication Data only includes the t= oken, the RS MUST respond with
=C2=A0 =C2=A0an AUTH packet, with the Aut= henticate Reason Code set to '0x18
=C2=A0 =C2=A0(Continue Authentica= tion)'.=C2=A0 This packet includes the Authentication
=C2=A0 =C2=A0M= ethod, which MUST be set to 'ace' and Authentication Data.=C2=A0 Th= e
=C2=A0 =C2=A0Authentication Data MUST NOT be empty and contains an 8-b= yte nonce as
=C2=A0 =C2=A0a challenge for the Client.=C2=A0 The Client r= esponds to this with an AUTH
=C2=A0 =C2=A0packet with a reason code '= ;0x18 (Continue Authentication)'.
=C2=A0 =C2=A0Similarly, the Client= packet sets the Authentication Method to 'ace'.
=C2=A0 =C2=A0Th= e Authentication Data in the Client's response contains a client-
= =C2=A0 =C2=A0generated 8-byte nonce, and the signature or MAC computed over= the RS
=C2=A0 =C2=A0nonce concatenated with the client nonce.=C2=A0 Nex= t, the token is
=C2=A0 =C2=A0validated as described in Section 2.2.5.

<mglt>I do not see exporters being involved, and if that is = correct there is no
channel binding. As DTLS is mandatory, wouldn't = it be possible to add the
exporter to the nonces. This may also be used = to increases the randomness of
the nonces</mglt>

[...]
<= br>3.1.=C2=A0 PUBLISH Messages from the Publisher Client to the Broker
<= br>=C2=A0 =C2=A0On receiving the PUBLISH message, the Broker MUST use the t= ype of
=C2=A0 =C2=A0message (i.e., PUBLISH) and the Topic name in the me= ssage header to
=C2=A0 =C2=A0match against the scope string in the cache= d token or its
=C2=A0 =C2=A0introspection result.=C2=A0 Following the ex= ample above, a client sending
=C2=A0 =C2=A0a PUBLISH message to 'a/t= opic3' would be allowed to publish, as the
=C2=A0 =C2=A0scope includ= es the string 'publish_+/topic3'.

=C2=A0 =C2=A0If the Client= is allowed to publish to the topic, the RS must publish

<mglt>= ;While "must" may not be necessary, if used, it could be normativ= e.</mglt>

=C2=A0 =C2=A0the message to all valid subscribers of= the topic.=C2=A0 In the case of an
=C2=A0 =C2=A0authorization failure, = an error MAY be returned to the Client.=C2=A0 For
=C2=A0 =C2=A0this the = QoS level of the PUBLISH message MUST be set to greater than
=C2=A0 =C2= =A0or equal to 1.=C2=A0 This guarantees that RS responds with either a PUBA= CK
=C2=A0 =C2=A0or PUBREC packet with reason code '0x87 (Not authori= zed)'.

=C2=A0 =C2=A0On receiving a PUBACK with '0x87 (Not au= thorized)', the Client MAY
=C2=A0 =C2=A0reauthenticate as described = in Section 4, and pass a new token
=C2=A0 =C2=A0following the same PoP m= ethods as described in Figure 2.

3.2.=C2=A0 PUBLISH Messages from th= e Broker to the Subscriber Clients

=C2=A0 =C2=A0To forward PUBLISH m= essages to the subscribing Clients, the Broker
=C2=A0 =C2=A0identifies a= ll the subscribers that have valid matching topic
=C2=A0 =C2=A0subscript= ions (i.e., the tokens are valid, and token scopes allow a
=C2=A0 =C2=A0= subscription to the particular topic).=C2=A0 The Broker sends a PUBLISH
= =C2=A0 =C2=A0message with the Topic name to all the valid subscribers.
<= br>=C2=A0 =C2=A0RS MUST stop forwarding messages to the unauthorized subscr= ibers.

<mgtl>I do not think they should have started. I am won= dering if s/stop/NOT/
would not be better.</mglt>

=C2=A0 = =C2=A0There is no way to inform the Clients with invalid tokens that an
= =C2=A0 =C2=A0authorization error has occurred other than sending a DISCONNE= CT
=C2=A0 =C2=A0message.=C2=A0 The RS SHOULD send a DISCONNECT message w= ith the reason
=C2=A0 =C2=A0code '0x87 (Not authorized)'.=C2=A0 = Note that the server-side DISCONNECT
=C2=A0 =C2=A0is a new feature of MQ= TT v5.0 (in MQTT v3.1.1, the server needs to
=C2=A0 =C2=A0drop the conne= ction).

[...]

4.=C2=A0 Token Expiration and Reauthentication<= br>
=C2=A0 =C2=A0The Broker MUST check for token expiration whenever a C= ONNECT,
=C2=A0 =C2=A0PUBLISH or SUBSCRIBE message is received or sent.= =C2=A0 The Broker SHOULD
=C2=A0 =C2=A0check for token expiration on rece= iving a PINGREQUEST message.=C2=A0 The
=C2=A0 =C2=A0Broker MAY also chec= k for token expiration periodically e.g., every
=C2=A0 =C2=A0hour.=C2=A0= This may allow for early detection of a token expiry.

=C2=A0 =C2=A0= The token expiration is checked by checking the 'exp' claim of a JW= T
=C2=A0 =C2=A0or introspection response, or via performing an introspec= tion request
=C2=A0 =C2=A0with the AS as described in Section 5.7 of the= ACE framework
=C2=A0 =C2=A0[I-D.ietf-ace-oauth-authz].=C2=A0 Token expi= rations may trigger the RS to
=C2=A0 =C2=A0send PUBACK, SUBACK and DISCO= NNECT messages with return code set to
=C2=A0 =C2=A0'Not authorised&= #39;.=C2=A0 After sending a DISCONNECT message, the network
=C2=A0 =C2= =A0connection is closed, and no more messages can be sent.=C2=A0 However, a= s
=C2=A0 =C2=A0a response to the PUBACK and SUBACK, the Client MAY re-au= thenticate
=C2=A0 =C2=A0by sending an AUTH packet with a Reason Code of = '0x19 (Re-
=C2=A0 =C2=A0authentication)'.

=C2=A0 =C2=A0To= re-authenticate, the Client sends an AUTH packet with reason code
=C2= =A0 =C2=A0'0x19 (Re-authentication)'.=C2=A0 The Client MUST set the= Authentication
=C2=A0 =C2=A0Method as 'ace' and transport the n= ew token in the Authentication
=C2=A0 =C2=A0Data.=C2=A0 The Client and t= he RS go through the same steps for proof of
=C2=A0 =C2=A0possession val= idation as described in Section 2.2.=C2=A0 The Client SHOULD
=C2=A0 =C2= =A0use the same method used for the first connection request.

<m= glt>I am wondering if there are good reasons for SHOULD. I would say tha= t
using multiple authentication method with different level of trust SHO= ULD be
avoided. </mglt>


































Sengul, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Expires June 22, 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0[Page 27]


On Fri, Jan 17, 2020 at = 9:40 PM Jim Schaad <ietf@augus= tcellars.com> wrote:

=C2=A0

=C2=A0

From: Cigdem Sengul <cigdem.sengul@gmail.com>
Sent: Tuesd= ay, January 14, 2020 8:25 AM
To: Jim Schaad <ietf@augustcellars.com>Cc: draft-ietf-ace-mqtt-tls-profile@ietf.org; Ace Wg <ace@ietf.org>
= Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-03<= u>

=C2=A0

Thank you for this review, Jim.=C2=A0<= u>

Responses inline.=C2=A0<= u>

=C2=A0

<= div>

On Wed, Jan 1, 2020 at 10:33 PM Jim Schaad <<= a href=3D"mailto:ietf@augustcellars.com" target=3D"_blank">ietf@augustcella= rs.com> wrote:




2.2.2 - I am un= clear under what circumstances you could end put with a token
which does= not parse when processing a PUBLISH message.=C2=A0 If the token cannot
= be parsed at connection time, that I can understand.=C2=A0 However having p= arsed
the token then it does not make sense that the token becomes not p= arsable at
the time of publishing.=C2=A0 Am I missing something?<= u>

=C2=A0

=

[CS] There is a misunderstanding. The PUB= LISH message refers to the actual PUBLISH message to the "authz-info&q= uot; topic which contains the token i.e., this may not parse to a token. (T= he PUBLISH message is not for other messages that are permissioned in the t= oken.)

The client connec= ts (without much security), publishes the token to the public "authz-i= nfo" topic, which only the broker can read.=C2=A0

Then, disconnects, and tries to connect with= ace security.=C2=A0

= =C2=A0

Since MQTT v5 can re= turn error messages in response to PUBLISH messages, here, this is used to = signal to the publisher that there is something wrong with its token.=C2=A0=

=C2=A0

Added:=C2=A0https://github.com/a= ce-wg/mqtt-tls-profile/issues/38

=C2=A0

[JLS] Ok =E2=80=93 I see w= here I got mixed in in reading this.=C2=A0 I think this may just be a probl= em on my end and you might not be able to do this better.

=

=C2=A0

=C2=A0

= =C2=A0


2.2.4 - I am having a problem with trying to parse the content of the = AUTH
property.=C2=A0 I have no problems with 2.2.4.3 because this is a z= ero length
sequence of bytes.=C2=A0 However for 2.2.4.1 and 2.2.4.2 ther= e is a token
(possibly binary with no length prefix) followed by an opti= onal binary
cryptographic value.=C2=A0 For introspection, I would need t= o figure out the
length of the token before I could make a guess at the = length of the
cryptographic value.=C2=A0 However given that there is no = divider this does not
seem possible.=C2=A0 This may also become a proble= m for the response from the
client in the event that there is a change f= rom an 8-byte nonce to a
variable length one.

=C2=A0

[CS] Not specified a=C2=A0 format, because I=C2=A0 thought w= e discarded the idea of using the variable-length nonce based on the meetin= g in Singapore.=C2=A0

Wh= at would you suggest - introduce a specific format to accommodate variable = length?

length_of_token+= binary data for token+(the rest is cryptographic value)?

<= /div>

=C2=A0https://github.com/ace-wg/mq= tt-tls-profile/issues/40

=C2=A0

[JLS] I put in a comment on the gi= thub issue about what I was looking for.=C2=A0 Additionally,=C2=A0 my only = possible problem with the fixed size nonce is that the IESG or Security Dir= ectorate down the line may decide that it is too small for some reason (16 = bytes signed by a 521-bit (65+ byte key)).=C2=A0 Some might consider it to = be small for a SHA-256 MAC operation.=C2=A0 Not the exact same situation he= re for TLS as it is not really a compact protocol.=C2=A0 But it may conside= red to be for the IoT variants being used.=C2=A0 I don=E2=80=99t know.

=C2=A0

=C2=A0

Jim

=C2=A0


I am going to play with = something else.=C2=A0 I am sure I will find other issues
at a different = time.

=C2= =A0

Thank you for your review. = Much appreciated.=C2=A0

= --Cigdem=C2=A0

=C2=A0=


Jim<= br>













Nits:
Section= 2 Para 1 s/Broker.Figure 1/Broker.=C2=A0 Figure 1/
Section 2 Para 1=C2= =A0 s/setup.The/setup.=C2=A0 The/
Section 2.2.2 Last Para s/when the AS/= when the RS/


_______________________________________________
= Ace mailing list
Ace@i= etf.org
https://www.ietf.org/mailman/listinfo/ace

=
__________________________= _____________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--00000000000062f872059caa80c2-- From nobody Tue Jan 21 13:36:02 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E90B2120019 for ; Tue, 21 Jan 2020 13:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kg38DHKj-0ln for ; Tue, 21 Jan 2020 13:35:55 -0800 (PST) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17FF61200A1 for ; Tue, 21 Jan 2020 13:35:55 -0800 (PST) Received: by mail-lf1-x12c.google.com with SMTP id y1so3580999lfb.6 for ; Tue, 21 Jan 2020 13:35:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nn1NWEslU/8NVBmZpCNjBFRfJ3OFtWvXu0a8G7cw3LM=; b=JPwL3PeD1/7Qk6R0vko0YHWF//cvN+ABTLDHpGvh/EbZoM0L8FbZtPm6awkGGW7gdD WDSxGIc4hf5bCD3I416FL73Dq4Zwzm2tKDftMtfFm/O4VnBtwrea4Sq1/ktet5sZeMTP mcU6TZ/3Efc66aqPKHWHu0mcVB8118UmRd4WDEAxcdVjqdMdH0r6bUM20/g9xRknba6L 7EQgm3A4Rs0cw5oAvcEF4V35n4w8wDbJjoEepU6GqOlnzbIhIWx7NLSeaxZdth//jGEt 7zFrF2EQJ607kSVE94AJa9CllYreT4++Nueg+OpUqcVkYj354B9mmZlPc7mlr2kQ5dyh WarQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nn1NWEslU/8NVBmZpCNjBFRfJ3OFtWvXu0a8G7cw3LM=; b=bnD5Z50U0PAiNNfCWzgn203FfK8iEc6Xp711KG2+4hyDOr4rvLv3VPQUBt8o/osSuI /Iwe58nyTqFqBMfC08RD/jO2sDFHyXFtOsujJRvqBmZICTXZMUEXI4bkTF9olvf7iinM 4pRk9uFgYSQUbi1nphfKVZmevvIFWrtPRA5NxorjcDUh9LLqty3zPHctEeWGrPMgUnUg 1fs8eL59irWp7p65Hadf6x/XeVPjmZZshZmMmPBcbRxO7ojYVzm9NzIfQ2Ql8cMxNk9x Es3uqqQ7CeZqWvkQjCWb2SuX3ydubLXt4O6/YoDnZnHF9Ceg2Yw6mF3Elenb6DCLjwfi FBZw== X-Gm-Message-State: APjAAAWPCBpzEGDg3kcF3WXKSUEVbVQ0jRiYGuSMQSJqiwYj7VcYXY/b aJKmqjg5oT1mGiWbP5Qf2ihLX65gYibDBPBItBhQSzIj1zlODfs/2Ug1ucB1I8PgCBt7/37nv+P evW1v3aey5pA= X-Google-Smtp-Source: APXvYqx3DlU2Qb081XChtQHsNKYYW+Ss7Qoc0KyoJov8K5ri71AuJZv+f9Y5nO+g3jdwnKQEeh/UAaoFh9pLeDJuie8= X-Received: by 2002:ac2:5f68:: with SMTP id c8mr3659659lfc.196.1579642553276; Tue, 21 Jan 2020 13:35:53 -0800 (PST) MIME-Version: 1.0 References: <9c32d171-9a4a-ba71-c989-92a177d9e989@gmx.de> <14a3c79d23e94d938be4a173a6c8256d@combitech.se> <504e86ae-f577-8526-e1cb-ed38d6a2e36f@gmx.de> In-Reply-To: <504e86ae-f577-8526-e1cb-ed38d6a2e36f@gmx.de> From: Brian Campbell Date: Tue, 21 Jan 2020 14:35:26 -0700 Message-ID: To: Ludwig Seitz Cc: Seitz Ludwig , Roman Danyliw , "jwt-reg-review@ietf.org" , Jim Schaad , The IESG , "ace@ietf.org" , "drafts-lastcall@iana.org" , Benjamin Kaduk Content-Type: multipart/alternative; boundary="00000000000042b246059cad317a" Archived-At: Subject: Re: [Ace] [Jwt-reg-review] Requested review for IANA registration in draft-ietf-ace-oauth-authz X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 21:36:01 -0000 --00000000000042b246059cad317a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Ludwig, -31 is improved with regard to my previous concerns about 'exi' On Sat, Jan 18, 2020 at 9:22 AM Ludwig Seitz wrote: > On 2020-01-13 22:01, Brian Campbell wrote: > > Thanks for the updates Lugwig, > > > > Section 6.6. does propose one mitigation for the unbounded memory growt= h > > problem. However, it relies on the AS to do pretty specific things with > > the content of other claims for it to even be possible for an RS to > > perform the mitigation approach. Do you think, for interoperability, it > > needs to be more prescriptive? Like maybe requiring the cti/jti claim > > with specific content and characteristics when exi is present or > > embedding/encoding that sequence number in the value of the exi itself > > alongside the lifetime of the token. > > > > > > This sounds like a reasonable requirement. I'm even inclined to make > that a MUST and not just a SHALL. Next update coming soon. > > /Ludwig > > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000042b246059cad317a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Ludwig, -31 is improved with regard to my previous = concerns about 'exi'

On Sat, Jan 18, 2020 at 9:22 AM Ludwig Sei= tz <ludwig_seitz@gmx.de> w= rote:
On 2020-01= -13 22:01, Brian Campbell wrote:
> Thanks for the updates Lugwig,
>
> Section 6.6. does propose one mitigation for the unbounded memory grow= th
> problem. However, it relies on the AS to do pretty specific things wit= h
> the content of other claims for it to even be possible for an RS to > perform the mitigation approach. Do you think, for interoperability, i= t
> needs to be more prescriptive? Like maybe requiring the cti/jti claim<= br> > with specific content and characteristics when exi is present or
> embedding/encoding that sequence number in the value of the exi itself=
> alongside the lifetime of the token.
>
>

This sounds like a reasonable requirement. I'm even inclined to make that a MUST and not just a SHALL. Next update coming soon.

/Ludwig



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000042b246059cad317a-- From nobody Thu Jan 23 17:12:38 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9F812022C; Mon, 20 Jan 2020 13:12:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id assKLZ5pfRKy; Mon, 20 Jan 2020 13:12:19 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 300201201DC; Mon, 20 Jan 2020 13:12:18 -0800 (PST) Received: from Jude (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 20 Jan 2020 13:12:11 -0800 From: Jim Schaad To: 'Brian Campbell' , 'Seitz Ludwig' , CC: 'Roman Danyliw' , , 'Daniel Migault' , , 'Ludwig Seitz' , 'Benjamin Kaduk' , References: <4a5177af-a442-f109-f620-0ae91953eb63@gmx.de> <2616175d102b4c19a60c6a79d4256b5e@combitech.se> <018601d5cf21$19cec7b0$4d6c5710$@augustcellars.com> In-Reply-To: <018601d5cf21$19cec7b0$4d6c5710$@augustcellars.com> Date: Mon, 20 Jan 2020 13:12:08 -0800 Message-ID: <004701d5cfd6$48f25650$dad702f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0048_01D5CF93.3AD35C10" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEhd6Yle2bwoestBETa2w8Xfe67igHXMmInAunJ6fMCAFODFgH28139AnlL6EUC9B5uh6jri79g Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: X-Mailman-Approved-At: Thu, 23 Jan 2020 17:12:34 -0800 Subject: Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 21:12:23 -0000 ------=_NextPart_000_0048_01D5CF93.3AD35C10 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I started doing testing of my code and I have started to run into some = massive problems with the confirmation claim. The COSE version of the = POP key registrations cause a problem because of the way the = registration template in the document is written. It currently says: =20 JWT Confirmation Method Name: =20 Claim Name of the equivalent JWT confirmation method value, as registered in [IANA.JWT.Claims = ]. CWT claims should normally have a corresponding JWT claim. If a corresponding JWT claim would not make sense, the Designated Experts can choose to accept registrations for which the JWT Claim Name is listed as "N/A". =20 The issue here is the word =E2=80=9Cequivalent=E2=80=9D. There are two = possible interpretations of this: That this is a similar item in terms = of how things are used, but there is no way to encode this item into a = JWT. Or, that this is how one should encode this item in a JWT. The = first interpretation implies that even though one would like to pass a = COSE_Key confirmation in a JWT there is no way to do this. (Yes, one = can potentially convert the COSE Key into a JOSE Key but that is not = always going to succeed as some keys in one system may not be = representable in the other system.) The second interpretation says that = you just encode the COSE_Key as JSON and put it into the map with the = =E2=80=9Djwk=E2=80=9D key and you are happy. Which of course will not = work. =20 I had misled myself in the message below as I had missed reading the JWT = Confirmation Method Name field in the registration templates. If you = look at the text below, it is hard to know if =E2=80=9CCOSE_Key=E2=80=9D = is to be used in a JSON structure (which I had originally assumed) or if = =E2=80=9Cjwk=E2=80=9D is supposed to be used in a JSON structure. =20 o Confirmation Method Name: "COSE_Key" o Confirmation Method Description: COSE_Key Representing Public Key o JWT Confirmation Method Name: "jwk" o Confirmation Key: 1 o Confirmation Value Type(s): COSE_Key structure o Change Controller: IESG o Specification Document(s): Section 3.2 = of [[ this document ]] =20 At a minimum we should probably clarify the language on this. And I = need to look at the COSE documents and decode if there needs to be some = text on encoding in a JSON environment or not. =20 Jim =20 =20 From: Ace On Behalf Of Jim Schaad Sent: Sunday, January 19, 2020 3:35 PM To: 'Brian Campbell' ; 'Seitz Ludwig' = Cc: 'Roman Danyliw' ; oauth-ext-review@ietf.org; 'Daniel = Migault' ; drafts-lastcall@iana.org; = 'Ludwig Seitz' ; 'Benjamin Kaduk' ; = ace@ietf.org Subject: Re: [Ace] Requested review for IANA registration in = draft-ietf-ace-oauth-params =20 I have managed to merge most of my code that deals with the confirmation = claim and I have ended up with a single problem when dealing with = confirmations. If this is going to get fixed, it needs to get fixed in = draft-ietf-ace-cwt-proof-of-possession prior to this document finishing = processing the EDIT process in the RFC editor. =20 All of the items that can appear in a confirmation claim are unique = except for the =E2=80=98kid=E2=80=99 claim method. This field is = defined as being a text field for JWT (RFC 7800), but it is defined as = being a binary field for CWT. It is a text field when defined in RFC = 7800. I do not anticipate any issues for the definition of a thumbprint = as COSE is using a very different format for the definition of = thumbprints which will led to a different naming convention. =20 Jim =20 =20 =20 From: Brian Campbell >=20 Sent: Monday, January 13, 2020 10:01 AM To: Seitz Ludwig > Cc: Ludwig Seitz >; = Roman Danyliw >; = oauth-ext-review@ietf.org ; Daniel = Migault >; Jim Schaad = >; Benjamin = Kaduk >; ace@ietf.org = ; drafts-lastcall@iana.org = =20 Subject: Re: [Ace] Requested review for IANA registration in = draft-ietf-ace-oauth-params =20 Thanks Ludwig, =20 On Sat, Jan 11, 2020 at 8:20 AM Seitz Ludwig > wrote: [snip]=20 =20 From: Ace > On = Behalf Of Brian Campbell =20 [snip] =20 So in -09 the "cnf" Introspection Response Parameter was the following = the syntax of the "cnf" claim from PoP Key Semantics for CWTs = [ID.ietf-ace-cwt-proof-of-possession] and in -10 it's following the = syntax of PoP Key Semantics for JWTs [RFC7800] transitively via = [I-D.ietf-oauth-mtls] reference. I think I understand that the two PoP = key semantics documents are conceptually the same or similar. But I = don't know that the syntax is the same? Figure 5 = = is pointed to for mapping between CBOR and JSON but it only has mappings = for the main top level parameters. Maybe I just don't get it or am = missing something... =20 =20 [LS] No you are not missing something, I just got sloppy trying to do a = quickfix. =20 Background: The reason for defining both JSON and CBOR-based = interactions is that you might have a powerful client communicating with = a constrained RS. The client does vanilla OAuth interactions with the AS = via the token endpoint, but is served a CWT and associated ACE = parameters (cnf, ace-profile, =E2=80=A6) for interaction with the RS.=20 The pop-key should decode to the same binary representation regardless = of whether it came in a JSON or CBOR wrapper. =20 Okay, so noting that there is cnf content that doesn't decode to a key, = I suppose I'll just take it on faith that all the relevant or expected = usages involve a key that can be represented in both CBOR and JSON.=20 CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. ------=_NextPart_000_0048_01D5CF93.3AD35C10 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I started = doing testing of my code and I have started to run into some massive = problems with the confirmation claim.=C2=A0 =C2=A0=C2=A0The COSE version = of the POP key registrations cause a problem because of the way the = registration template in the document is written.=C2=A0 It currently = says:

 

JWT =
Confirmation Method Name:

 

Claim Name of the = equivalent JWT confirmation method value, as

registered in [IANA.JWT.Claims].=C2=A0 CWT claims should normally = have

a corresponding JWT = claim.=C2=A0 If a corresponding JWT claim would = not

make sense, the = Designated Experts can choose to accept

registrations for which the JWT Claim Name is listed as = "N/A".

 

The issue = here is the word =E2=80=9Cequivalent=E2=80=9D.=C2=A0 There are two = possible interpretations of this:=C2=A0 That this is a similar item in = terms of how things are used, but there is no way to encode this item = into a JWT.=C2=A0 Or, that this is how one should encode this item in a = JWT.=C2=A0 The first interpretation implies that even though one would = like to pass a COSE_Key confirmation in a JWT there is no way to do = this.=C2=A0 (Yes, one can potentially convert the COSE Key into a JOSE = Key but that is not always going to succeed as some keys in one system = may not be representable in the other system.) The second interpretation = says that you just encode the COSE_Key as JSON and put it into the map = with the =E2=80=9Djwk=E2=80=9D key and you are happy.=C2=A0 Which of = course will not work.

 

I had misled = myself in the message below as I had missed reading the JWT Confirmation = Method Name field in the registration templates.=C2=A0 =C2=A0If you look = at the text below, it is hard to know if =E2=80=9CCOSE_Key=E2=80=9D is = to be used in a JSON structure (which I had originally assumed) or if = =E2=80=9Cjwk=E2=80=9D is supposed to be used in a JSON = structure.

 

 =
=C2=A0=C2=A0o=C2=A0 Confirmation Method Name: =
"COSE_Key"
=C2=A0=C2=A0 o=C2=A0 =
Confirmation Method Description: COSE_Key Representing Public =
Key
=C2=A0=C2=A0 o=C2=A0 JWT Confirmation Method =
Name: "jwk"
=C2=A0=C2=A0 o=C2=A0 =
Confirmation Key: 1
=C2=A0=C2=A0 o=C2=A0 =
Confirmation Value Type(s): COSE_Key =
structure
=C2=A0=C2=A0 o=C2=A0 Change Controller: =
IESG
=C2=A0=C2=A0 o=C2=A0 Specification =
Document(s): Section 3.2 of [[ this document =
]]

 

At a minimum we should probably clarify the language = on this.=C2=A0 And I need to look at the COSE documents and decode if = there needs to be some text on encoding in a JSON environment or = not.

 

Jim

 

 

From: Ace = <ace-bounces@ietf.org> On Behalf Of Jim = Schaad
Sent: Sunday, January 19, 2020 3:35 PM
To: = 'Brian Campbell' <bcampbell@pingidentity.com>; 'Seitz Ludwig' = <ludwig.seitz@combitech.se>
Cc: 'Roman Danyliw' = <rdd@cert.org>; oauth-ext-review@ietf.org; 'Daniel Migault' = <daniel.migault@ericsson.com>; drafts-lastcall@iana.org; 'Ludwig = Seitz' <ludwig_seitz@gmx.de>; 'Benjamin Kaduk' = <kaduk@mit.edu>; ace@ietf.org
Subject: Re: [Ace] = Requested review for IANA registration in = draft-ietf-ace-oauth-params

 

I have = managed to merge most of my code that deals with the confirmation claim = and I have ended up with a single problem when dealing with = confirmations.  If this is going to get fixed, it needs to get = fixed in draft-ietf-ace-cwt-proof-of-possession prior to this document = finishing processing the EDIT process in the RFC = editor.

 

All of the items that can appear in a confirmation = claim are unique except for the =E2=80=98kid=E2=80=99 claim = method.  This field is defined as being a text field for JWT (RFC = 7800), but it is defined as being a binary field for CWT.  It is a = text field when defined in RFC 7800.  I do not anticipate any = issues for the definition of a thumbprint as COSE is using a very = different format for the definition of thumbprints which will led to a = different naming convention.

 

Jim

 

 

 

From: = Brian Campbell <bcampbell@pingidentity.com= >
Sent: Monday, January 13, 2020 10:01 AM
To: = Seitz Ludwig <ludwig.seitz@combitech.se&g= t;
Cc: Ludwig Seitz <ludwig_seitz@gmx.de>; Roman = Danyliw <rdd@cert.org>; oauth-ext-review@ietf.org; = Daniel Migault <daniel.migault@ericsson.com>; Jim Schaad <ietf@augustcellars.com>; = Benjamin Kaduk <kaduk@mit.edu>; ace@ietf.org; drafts-lastcall@iana.org
= Subject: Re: [Ace] Requested review for IANA registration in = draft-ietf-ace-oauth-params

 

Thanks Ludwig,

 

On = Sat, Jan 11, 2020 at 8:20 AM Seitz Ludwig <ludwig.seitz@combitech.se> = wrote:

[snip]

 

From:= Ace <ace-bounces@ietf.org> On Behalf Of Brian = Campbell

 <= /o:p>

[snip]

  =                  =

So in -09 = the "cnf" Introspection Response Parameter was the following = the syntax of the "cnf" claim from PoP Key Semantics for CWTs = [ID.ietf-ace-cwt-proof-of-possession] and in -10 it's following the = syntax of PoP Key Semantics for JWTs [RFC7800] transitively via = [I-D.ietf-oauth-mtls] reference. I think I understand that the two PoP = key semantics documents are conceptually the same or similar. But I = don't know that the syntax is the same? Figure 5 is pointed to for mapping between = CBOR and JSON but it only has mappings for the main top level = parameters. Maybe I just don't get it or am missing something...   =

 <= /o:p>

[LS] No you are not missing something, I just = got sloppy trying to do a quickfix.

 

Background: The reason for defining both JSON = and CBOR-based interactions is that you might have a powerful client = communicating with a constrained RS. The client does vanilla OAuth = interactions with the AS via the token endpoint, but is served a CWT and = associated ACE parameters (cnf, ace-profile, =E2=80=A6) for interaction = with the RS.

The pop-key should decode to the same binary = representation regardless of whether it came in a JSON or CBOR = wrapper.

<= p class=3DMsoNormal> 

Okay, so noting that there is cnf content that doesn't = decode to a key, I suppose I'll just take it on faith that all the = relevant or expected usages involve a key that can be represented in = both CBOR and JSON.


CONFIDENTIALITY NOTICE: This email may contain = confidential and privileged material for the sole use of the intended = recipient(s). Any review, use, distribution or disclosure by others is = strictly prohibited.  If you have received this communication in = error, please notify the sender immediately by e-mail and delete the = message and any file attachments from your computer. Thank = you.

------=_NextPart_000_0048_01D5CF93.3AD35C10-- From nobody Thu Jan 23 17:12:42 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE91F120077 for ; Thu, 23 Jan 2020 13:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JS-RrlGj-iiy for ; Thu, 23 Jan 2020 13:31:49 -0800 (PST) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF5AB12011C for ; Thu, 23 Jan 2020 13:31:48 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id h23so5402155ljc.8 for ; Thu, 23 Jan 2020 13:31:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UJfgky6Wlrj0vVNTfhi18OCtvPiz6ZLKvn6pTlY6Pr0=; b=Xrlnd++ccjZ7GLZJ85OJxt9D83eZ/ZuoOUO0fGLd4F0AMtxhCl3zGepqjmTkVyvXQw Kll3bFUXMwz8DyuAVJhq6HyaUc5CH1ucs2ugS2jgRf4viCm1roTOvMpI4H+Lb+n39XX6 9BFLm2JDAe0xanA/V57RydWoxL7TaiIkt5XPw367E+GvWZom5KnBk11glYmRBaQCSTlc wvBSnnpvMG8DXJYxFAldURT/dNAHu07NcIF5CKRp4Evti8PStK619tFY/G2goBHSuFw0 SXdQEa++l8QXJWmSxM+jbcfJzpmNzcKn7ZizSXgv/kgSLFDQyPEEmyzRIfEJLUlGgbO1 wHKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UJfgky6Wlrj0vVNTfhi18OCtvPiz6ZLKvn6pTlY6Pr0=; b=QYmGzDYGx8EgavuP/QXU3TRA17gYe1P3GMMI82qssQTxNmXQG1FYIWoLtas8mlK40I rxTBNS3qkCuQOpf5Fq4L92QnYRqyHW9CoJcVAQNcce2/QXP3B4YwMjul7PEotwWwORSm HvQlSD7PGuO8EQ24xChlsGfXiI2/VoXHMkZbLZz7AK+eQwkdR0bIhOSuA7UuqzsU6xbd 8EIJ2qfL++jDxPiyBBPvvjVRrQWLIDkJkZOxnakbpsVCKX1ZhF4m19EKgz3C3uI38rWz qmTf7Sgvsh64Nuy8jawgpWPVDrZD/tuHUFNPpYJPGQ0Byp9NJfFOV2aFhXD1gOjzci0P d3Pg== X-Gm-Message-State: APjAAAVuA7rtbPol/GSe0v2lFTIxs9SPW0a6fENOjxcSzzfN7Aiy/P1j iLKNbNDjKY6wBVRCTh0ltzBBsgvPXbyf1zzK5Z9IkiN+dFnHQmXx2WRBCQnzv4ExGE81fzqBhH6 5OAhBquTt2gk= X-Google-Smtp-Source: APXvYqxClnrO17gdfqHHx6uJ9kHJok2F1vqjzkY1rEfr0h+tHDeJl8x7mLtWDfExoaKtaUl8ySubekp//r3bXUPRRY0= X-Received: by 2002:a2e:b4ef:: with SMTP id s15mr268566ljm.20.1579815106958; Thu, 23 Jan 2020 13:31:46 -0800 (PST) MIME-Version: 1.0 References: <9c32d171-9a4a-ba71-c989-92a177d9e989@gmx.de> <77781da882414f4aae98ae2443691933@combitech.se> <582bfd3fbdee4cc592b92857c955721b@combitech.se> In-Reply-To: <582bfd3fbdee4cc592b92857c955721b@combitech.se> From: Brian Campbell Date: Thu, 23 Jan 2020 14:31:20 -0700 Message-ID: To: Seitz Ludwig Cc: Ludwig Seitz , Roman Danyliw , "oauth-ext-review@ietf.org" , Daniel Migault , Jim Schaad , Benjamin Kaduk , "ace@ietf.org" , "drafts-lastcall@iana.org" , jwt-reg-review@ietf.org Content-Type: multipart/alternative; boundary="00000000000042f0e5059cd55e31" Archived-At: X-Mailman-Approved-At: Thu, 23 Jan 2020 17:12:34 -0800 Subject: Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 21:31:53 -0000 --00000000000042f0e5059cd55e31 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Apologies, I forgot to reply-all at some earlier point and dropped the mailing lists and other cc's off the thread. Added back now. And also apologies because I think I need to recuse myself from the DE responsibility on the JWT registry request here. I've spent more time than I'd like to admit or really have to spare on it and am still struggling to understand. I appreciate you pointing out the authz-info endpoint in ACE but I still don't follow how "rs_cnf" in an access token would really work in practice. The client sends the token to the RS's authz-info endpoint on an insecure connection or one that has the server auth with potentially different key and the RS stores the access token for later use. Then on resource access the RS looks up the access token (with respect to the cnf key in it) based on the key the client used in establishing a new mutually authentication connection to the RS. For the RS to choose a key for server it will use during the handshake (and as far as I know the server key is the first in the authn process of the handshake) based on the "rs_cnf" in the access token, it needs to remember and associate that client and the access token with something else (IP address?) that will be available during the handshake. It doesn't fit together for me in a way that seems likely to work or be interoperable but, like I said, I'm really struggling to understand. On Thu, Jan 16, 2020 at 12:54 AM Seitz Ludwig wrote: > Hi Brian, > > > > Comments inline. > > > > /Ludwig > > > > *From:* Brian Campbell > *Sent:* den 13 januari 2020 21:22 > *To:* Seitz Ludwig > *Subject:* Re: [Ace] Requested review for IANA registration in > draft-ietf-ace-oauth-params > > > > Thanks for the response and updates Ludwig, > > > > Please bear with me while I try to wrap my head around some things. > > > > The JWT registration request for the "rs_cnf" claim points to Sec 3.3 > > saying it is "a hint [in the access token] to the RS about which key it > should use to authenticate towards the client". But doesn't the client > have to go through the DTLS/TLS handshake with the RS (which is presumabl= y > when it authenticates to the client) before it presents the access token? > I'm not seeing how this would work as seems the RS won't see the hint unt= il > after it needs it. > > > > > > [LS] Not in the ACE flow. We use the access token to establish keys at th= e > RS both for the client and the RS. We have therefore defined a new > ACE-OAuth endpoint (authz-info) at the RS. The client can POST access > tokens to this endpoint without prior authentication. > > At that point, the RS only validates the signature/MAC by the AS. > > > > Later at the time of access, the corresponding token is linked to the > access request via the pop-mechanism and the client/access specific parts > are validated (e.g. scope, subject). > > > > Hope that clarifies things a bit. > > > > On Sat, Jan 11, 2020 at 8:30 AM Seitz Ludwig > wrote: > > Hello again Brian, > > > > Thank you for reviewing this! Indeed the handling of JWT/JSON interaction= s > was handled sloppily here. I will soon issue a draft update that specifie= s > that the JSON-based interactions should use the syntax from RFC7800 while > the CBOR-based ones should use ID.ietf-ace-cwt-proof-of-possession. > > > > This correction goes for all the use of =E2=80=9Ccnf=E2=80=9D, =E2=80=9Cr= eq_cnf=E2=80=9D and =E2=80=9Crs_cnf=E2=80=9D. > > > > Regards, > > > > Ludwig > > > > *From:* Ace *On Behalf Of *Brian Campbell > *Sent:* den 10 januari 2020 22:12 > *To:* Ludwig Seitz > *Cc:* Roman Danyliw ; jwt-reg-review@ietf.org; Jim Schaad < > ietf@augustcellars.com>; The IESG ; ace@ietf.org; > drafts-lastcall@iana.org; Benjamin Kaduk > *Subject:* Re: [Ace] Requested review for IANA registration in > draft-ietf-ace-oauth-params > > > > That "rs_cnf" claim registration request in 9.1 points to 3.3 which says > it has 'the same syntax and semantics as defined in for the "rs_cnf" > parameter', which I think is in 4.1. And 4.1 says that the "rs_cnf" value= s > 'follow the syntax of the "cnf" claim from section 3.1 of > [I-D.ietf-ace-cwt-proof-of-possession].' Similar to other comments I've > made today, I don't follow what that would mean for the value of the clai= m > when it's a JWT. And that seems like something that's important to > understand for the purpose of a JWT claims registry request. > > > > > > On Sat, Dec 21, 2019 at 4:11 AM Ludwig Seitz wrote: > > Hello JWT registry reviewers, > > the IESG-designated experts for the JWT claims registry have asked me to > send a review request to you about the "rs_cnf" claim registered here: > > https://tools.ietf.org/html/draft-ietf-ace-oauth-params-07#section-9.1 > > Thank you in advance for you review comments. > > Regards, > > Ludwig > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000042f0e5059cd55e31 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Apologies, I forgot to reply-all at some earlier poin= t and dropped the mailing lists and other cc's off the thread. Added ba= ck now.

And also apologies because I think I = need to recuse myself from the DE responsibility on the JWT registry reques= t here. I've spent more time than I'd like to admit or really have = to spare on it and am still struggling to understand.

I appreciate you pointing out the authz-info endpoint in ACE but I= still don't follow how "rs_cnf" in an access token would rea= lly work in practice. The client sends the token to the RS's authz-info= endpoint on an insecure connection or one that has the server auth with po= tentially different key and the RS stores the access token for later use. T= hen on resource access the RS looks up the access token (with respect to th= e cnf key in it) based on the key the client used in establishing a new mut= ually authentication connection to the RS. For the RS to choose a key for s= erver it will use during the handshake (and as far as I know the server key= is the first in the authn process of the handshake) based on the "rs_= cnf" in the access token, it needs to remember and associate that clie= nt and the access token with something else (IP address?) that will be avai= lable during the handshake. It doesn't fit together for me in a way tha= t seems likely to work or be interoperable but, like I said, I'm really= struggling to understand.

On Thu, Jan 16, 2020 at 12:54 AM Seitz Ludwi= g <ludwig.seitz@combitech.s= e> wrote:

Hi Brian,

=C2=A0

Comments inline.

=C2=A0

/Ludwig

=C2=A0

From: Brian Campbell <bcampbell@pingidentity.com= >
Sent: den 13 januari 2020 21:22
To: Seitz Ludwig <ludwig.seitz@combitech.se>
Subject: Re: [Ace] Requested review for IANA registration in draft-i= etf-ace-oauth-params

=C2=A0

Thanks for the response and updates Ludwig,

=C2=A0

Please bear with me while I try to wrap my head arou= nd some things.

=C2=A0

The JWT registration request for the "rs_cnf&qu= ot; claim points to Sec 3.3 saying it is "a hint [in the access token] to the RS about= which key it should use to authenticate towards the client".=C2=A0 Bu= t doesn't the client have to go through the DTLS/TLS handshake with the= RS (which is presumably when it authenticates to the client) before it presents the access token? I'm not seeing how this w= ould work as seems the RS won't see the hint until after it needs it.

=C2=A0

=C2=A0

[LS] Not in the= ACE flow. We use the access token to establish keys at the RS both for the= client and the RS. We have therefore defined a new ACE-OAuth endpoint (aut= hz-info) at the RS. The client can POST access tokens to this endpoint without prior authentication.

At that point, = the RS only validates the signature/MAC by the AS.

=C2=A0

Later at the ti= me of access, the corresponding token is linked to the access request via t= he pop-mechanism and the client/access specific parts are validated (e.g. s= cope, subject).

=C2=A0

Hope that clari= fies things a bit.

=C2=A0

On Sat, Jan 11, 2020 at 8:30 AM Seitz Ludwig <ludwig.seitz@co= mbitech.se> wrote:

Hello again Brian,=

=C2=A0

Thank you for reviewing this! In= deed the handling of JWT/JSON interactions was handled sloppily here. I will soon issue a draft update that specifies that the JSON-based intera= ctions should use the syntax from RFC7800 while the CBOR-based ones should = use ID.ietf-ace-cwt-proof-of-possession.

=C2=A0

This correction goes for all the= use of =E2=80=9Ccnf=E2=80=9D, =E2=80=9Creq_cnf=E2=80=9D and =E2=80=9Crs_cn= f=E2=80=9D.

=C2=A0

Regards,

=C2=A0

Ludwig

=C2=A0

From: Ace <ace-bounces@ietf.org> On Behalf Of Brian Campbell
Sent: den 10 januari 2020 22:12
To: Ludwig Seitz <ludwig_seitz@gmx.de>
Cc: Roman Danyliw <rdd@cert.org>; jwt-reg-review= @ietf.org; Jim Schaad <ietf@augustcellars.com>; The IESG <iesg@ietf.org>; ace@ietf.org; drafts-lastcall@iana.org; Benjamin Kaduk <kaduk@mit.edu>
Subject: Re: [Ace] Requested review for IANA registration in draft-i= etf-ace-oauth-params

=C2=A0

That=C2=A0 "rs_cnf" claim registration req= uest in 9.1 points to 3.3 which says it has 'the same syntax and semant= ics as defined in for the "rs_cnf" parameter', which I think = is in 4.1. And 4.1 says that the "rs_cnf" values 'follow the syntax of = the "cnf" claim from section 3.1 of [I-D.ietf-ace-cwt-proof-of-po= ssession].' Similar to other comments I've made today, I don't = follow what that would mean for the value of the claim when it's a JWT. And that seems like something that's important to understand for the p= urpose of a JWT claims registry request.=C2=A0

=C2=A0

=C2=A0


CONFIDENTI= ALITY NOTICE: This email may contain confidential and privileged material f= or the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibit= ed..=C2=A0 If you have received this communication in error, please notify = the sender immediately by e-mail and delete the message and any file attach= ments from your computer. Thank you.


CONFIDENTI= ALITY NOTICE: This email may contain confidential and privileged material f= or the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibit= ed.=C2=A0 If you have received this communication in error, please notify t= he sender immediately by e-mail and delete the message and any file attachm= ents from your computer. Thank you.


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000042f0e5059cd55e31-- From nobody Thu Jan 23 22:35:24 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACBD51200FD; Thu, 23 Jan 2020 17:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrrtvETf8wSJ; Thu, 23 Jan 2020 17:40:37 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5D301200E6; Thu, 23 Jan 2020 17:40:36 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00O1dolH031226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 23 Jan 2020 20:39:52 -0500 Date: Thu, 23 Jan 2020 17:39:49 -0800 From: Benjamin Kaduk To: Jim Schaad Cc: "'Brian Campbell'" , "'Seitz Ludwig'" , draft-ietf-ace-cwt-proof-of-possession@ietf.org, "'Roman Danyliw'" , oauth-ext-review@ietf.org, "'Daniel Migault'" , drafts-lastcall@iana.org, "'Ludwig Seitz'" , ace@ietf.org Message-ID: <20200124013949.GD90660@kduck.mit.edu> References: <4a5177af-a442-f109-f620-0ae91953eb63@gmx.de> <2616175d102b4c19a60c6a79d4256b5e@combitech.se> <018601d5cf21$19cec7b0$4d6c5710$@augustcellars.com> <004701d5cfd6$48f25650$dad702f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <004701d5cfd6$48f25650$dad702f0$@augustcellars.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: X-Mailman-Approved-At: Thu, 23 Jan 2020 22:35:23 -0800 Subject: Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 01:40:41 -0000 I want to double-check that I'm understanding you correctly. The idea is that there's ambiguity about how a CWT 'cnf' claim would get represented as "equivalent" JWT, and that it may not even be possible for some 'cnf' values? I'm not entirely sure what the path forward even looks like, and thus am inclined to believe that I should request an IESG hold on the publication of draft-ietf-ace-cwt-proof-of-possession. Is that right? Thanks, Ben On Mon, Jan 20, 2020 at 01:12:08PM -0800, Jim Schaad wrote: > I started doing testing of my code and I have started to run into some massive problems with the confirmation claim. The COSE version of the POP key registrations cause a problem because of the way the registration template in the document is written. It currently says: > > > > JWT Confirmation Method Name: > > > > Claim Name of the equivalent JWT confirmation method value, as > > registered in [IANA.JWT.Claims ]. CWT claims should normally have > > a corresponding JWT claim. If a corresponding JWT claim would not > > make sense, the Designated Experts can choose to accept > > registrations for which the JWT Claim Name is listed as "N/A". > > > > The issue here is the word “equivalent”. There are two possible interpretations of this: That this is a similar item in terms of how things are used, but there is no way to encode this item into a JWT. Or, that this is how one should encode this item in a JWT. The first interpretation implies that even though one would like to pass a COSE_Key confirmation in a JWT there is no way to do this. (Yes, one can potentially convert the COSE Key into a JOSE Key but that is not always going to succeed as some keys in one system may not be representable in the other system.) The second interpretation says that you just encode the COSE_Key as JSON and put it into the map with the ”jwk” key and you are happy. Which of course will not work. > > > > I had misled myself in the message below as I had missed reading the JWT Confirmation Method Name field in the registration templates. If you look at the text below, it is hard to know if “COSE_Key” is to be used in a JSON structure (which I had originally assumed) or if “jwk” is supposed to be used in a JSON structure. > > > > o Confirmation Method Name: "COSE_Key" > o Confirmation Method Description: COSE_Key Representing Public Key > o JWT Confirmation Method Name: "jwk" > o Confirmation Key: 1 > o Confirmation Value Type(s): COSE_Key structure > o Change Controller: IESG > o Specification Document(s): Section 3.2 of [[ this document ]] > > > > At a minimum we should probably clarify the language on this. And I need to look at the COSE documents and decode if there needs to be some text on encoding in a JSON environment or not. > > > > Jim > > > > > > From: Ace On Behalf Of Jim Schaad > Sent: Sunday, January 19, 2020 3:35 PM > To: 'Brian Campbell' ; 'Seitz Ludwig' > Cc: 'Roman Danyliw' ; oauth-ext-review@ietf.org; 'Daniel Migault' ; drafts-lastcall@iana.org; 'Ludwig Seitz' ; 'Benjamin Kaduk' ; ace@ietf.org > Subject: Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params > > > > I have managed to merge most of my code that deals with the confirmation claim and I have ended up with a single problem when dealing with confirmations. If this is going to get fixed, it needs to get fixed in draft-ietf-ace-cwt-proof-of-possession prior to this document finishing processing the EDIT process in the RFC editor. > > > > All of the items that can appear in a confirmation claim are unique except for the ‘kid’ claim method. This field is defined as being a text field for JWT (RFC 7800), but it is defined as being a binary field for CWT. It is a text field when defined in RFC 7800. I do not anticipate any issues for the definition of a thumbprint as COSE is using a very different format for the definition of thumbprints which will led to a different naming convention. > > > > Jim > > > > > > > > From: Brian Campbell > > Sent: Monday, January 13, 2020 10:01 AM > To: Seitz Ludwig > > Cc: Ludwig Seitz >; Roman Danyliw >; oauth-ext-review@ietf.org ; Daniel Migault >; Jim Schaad >; Benjamin Kaduk >; ace@ietf.org ; drafts-lastcall@iana.org > Subject: Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params > > > > Thanks Ludwig, > > > > On Sat, Jan 11, 2020 at 8:20 AM Seitz Ludwig > wrote: > > [snip] > > > > From: Ace > On Behalf Of Brian Campbell > > > > [snip] > > > > So in -09 the "cnf" Introspection Response Parameter was the following the syntax of the "cnf" claim from PoP Key Semantics for CWTs [ID.ietf-ace-cwt-proof-of-possession] and in -10 it's following the syntax of PoP Key Semantics for JWTs [RFC7800] transitively via [I-D.ietf-oauth-mtls] reference. I think I understand that the two PoP key semantics documents are conceptually the same or similar. But I don't know that the syntax is the same? Figure 5 is pointed to for mapping between CBOR and JSON but it only has mappings for the main top level parameters. Maybe I just don't get it or am missing something... > > > > [LS] No you are not missing something, I just got sloppy trying to do a quickfix. > > > > Background: The reason for defining both JSON and CBOR-based interactions is that you might have a powerful client communicating with a constrained RS. The client does vanilla OAuth interactions with the AS via the token endpoint, but is served a CWT and associated ACE parameters (cnf, ace-profile, …) for interaction with the RS. > > The pop-key should decode to the same binary representation regardless of whether it came in a JSON or CBOR wrapper. > > > > Okay, so noting that there is cnf content that doesn't decode to a key, I suppose I'll just take it on faith that all the relevant or expected usages involve a key that can be represented in both CBOR and JSON. > > > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. > From nobody Thu Jan 23 22:35:30 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6771200CD; Thu, 23 Jan 2020 17:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3cmBjXRiF-r; Thu, 23 Jan 2020 17:46:31 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD8E1120019; Thu, 23 Jan 2020 17:46:30 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00O1jnG6032496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 23 Jan 2020 20:45:51 -0500 Date: Thu, 23 Jan 2020 17:45:48 -0800 From: Benjamin Kaduk To: Brian Campbell Cc: Seitz Ludwig , Ludwig Seitz , Roman Danyliw , "oauth-ext-review@ietf.org" , Daniel Migault , Jim Schaad , "ace@ietf.org" , "drafts-lastcall@iana.org" , jwt-reg-review@ietf.org Message-ID: <20200124014548.GE90660@kduck.mit.edu> References: <9c32d171-9a4a-ba71-c989-92a177d9e989@gmx.de> <77781da882414f4aae98ae2443691933@combitech.se> <582bfd3fbdee4cc592b92857c955721b@combitech.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: X-Mailman-Approved-At: Thu, 23 Jan 2020 22:35:23 -0800 Subject: Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 01:46:34 -0000 Thanks for putting the effort in, Brian. IANA, do you need to assign a new expert to reviewi the JWT Claims registration request from this document, or are the experts expected to be self-organizing here? Thanks, Ben On Thu, Jan 23, 2020 at 02:31:20PM -0700, Brian Campbell wrote: > Apologies, I forgot to reply-all at some earlier point and dropped the > mailing lists and other cc's off the thread. Added back now. > > And also apologies because I think I need to recuse myself from the DE > responsibility on the JWT registry request here. I've spent more time than > I'd like to admit or really have to spare on it and am still struggling to > understand. > > I appreciate you pointing out the authz-info endpoint in ACE but I still > don't follow how "rs_cnf" in an access token would really work in practice. > The client sends the token to the RS's authz-info endpoint on an insecure > connection or one that has the server auth with potentially different key > and the RS stores the access token for later use. Then on resource access > the RS looks up the access token (with respect to the cnf key in it) based > on the key the client used in establishing a new mutually authentication > connection to the RS. For the RS to choose a key for server it will use > during the handshake (and as far as I know the server key is the first in > the authn process of the handshake) based on the "rs_cnf" in the access > token, it needs to remember and associate that client and the access token > with something else (IP address?) that will be available during the > handshake. It doesn't fit together for me in a way that seems likely to > work or be interoperable but, like I said, I'm really struggling to > understand. > > On Thu, Jan 16, 2020 at 12:54 AM Seitz Ludwig > wrote: > > > Hi Brian, > > > > > > > > Comments inline. > > > > > > > > /Ludwig > > > > > > > > *From:* Brian Campbell > > *Sent:* den 13 januari 2020 21:22 > > *To:* Seitz Ludwig > > *Subject:* Re: [Ace] Requested review for IANA registration in > > draft-ietf-ace-oauth-params > > > > > > > > Thanks for the response and updates Ludwig, > > > > > > > > Please bear with me while I try to wrap my head around some things. > > > > > > > > The JWT registration request for the "rs_cnf" claim points to Sec 3.3 > > > > saying it is "a hint [in the access token] to the RS about which key it > > should use to authenticate towards the client". But doesn't the client > > have to go through the DTLS/TLS handshake with the RS (which is presumably > > when it authenticates to the client) before it presents the access token? > > I'm not seeing how this would work as seems the RS won't see the hint until > > after it needs it. > > > > > > > > > > > > [LS] Not in the ACE flow. We use the access token to establish keys at the > > RS both for the client and the RS. We have therefore defined a new > > ACE-OAuth endpoint (authz-info) at the RS. The client can POST access > > tokens to this endpoint without prior authentication. > > > > At that point, the RS only validates the signature/MAC by the AS. > > > > > > > > Later at the time of access, the corresponding token is linked to the > > access request via the pop-mechanism and the client/access specific parts > > are validated (e.g. scope, subject). > > > > > > > > Hope that clarifies things a bit. > > > > > > > > On Sat, Jan 11, 2020 at 8:30 AM Seitz Ludwig > > wrote: > > > > Hello again Brian, > > > > > > > > Thank you for reviewing this! Indeed the handling of JWT/JSON interactions > > was handled sloppily here. I will soon issue a draft update that specifies > > that the JSON-based interactions should use the syntax from RFC7800 while > > the CBOR-based ones should use ID.ietf-ace-cwt-proof-of-possession. > > > > > > > > This correction goes for all the use of “cnf”, “req_cnf” and “rs_cnf”. > > > > > > > > Regards, > > > > > > > > Ludwig > > > > > > > > *From:* Ace *On Behalf Of *Brian Campbell > > *Sent:* den 10 januari 2020 22:12 > > *To:* Ludwig Seitz > > *Cc:* Roman Danyliw ; jwt-reg-review@ietf.org; Jim Schaad < > > ietf@augustcellars.com>; The IESG ; ace@ietf.org; > > drafts-lastcall@iana.org; Benjamin Kaduk > > *Subject:* Re: [Ace] Requested review for IANA registration in > > draft-ietf-ace-oauth-params > > > > > > > > That "rs_cnf" claim registration request in 9.1 points to 3.3 which says > > it has 'the same syntax and semantics as defined in for the "rs_cnf" > > parameter', which I think is in 4.1. And 4.1 says that the "rs_cnf" values > > 'follow the syntax of the "cnf" claim from section 3.1 of > > [I-D.ietf-ace-cwt-proof-of-possession].' Similar to other comments I've > > made today, I don't follow what that would mean for the value of the claim > > when it's a JWT. And that seems like something that's important to > > understand for the purpose of a JWT claims registry request. > > > > > > > > > > > > On Sat, Dec 21, 2019 at 4:11 AM Ludwig Seitz wrote: > > > > Hello JWT registry reviewers, > > > > the IESG-designated experts for the JWT claims registry have asked me to > > send a review request to you about the "rs_cnf" claim registered here: > > > > https://tools.ietf.org/html/draft-ietf-ace-oauth-params-07#section-9.1 > > > > Thank you in advance for you review comments. > > > > Regards, > > > > Ludwig > > > > _______________________________________________ > > Ace mailing list > > Ace@ietf.org > > https://www.ietf.org/mailman/listinfo/ace > > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > > privileged material for the sole use of the intended recipient(s). Any > > review, use, distribution or disclosure by others is strictly prohibited.. > > If you have received this communication in error, please notify the sender > > immediately by e-mail and delete the message and any file attachments from > > your computer. Thank you.* > > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > > privileged material for the sole use of the intended recipient(s). Any > > review, use, distribution or disclosure by others is strictly prohibited. > > If you have received this communication in error, please notify the sender > > immediately by e-mail and delete the message and any file attachments from > > your computer. Thank you.* > > > > -- > _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited.  If you have > received this communication in error, please notify the sender immediately > by e-mail and delete the message and any file attachments from your > computer. Thank you._ From nobody Fri Jan 24 04:37:52 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0624120043; Fri, 24 Jan 2020 04:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ConGGjFkLPI; Fri, 24 Jan 2020 04:37:48 -0800 (PST) Received: from mail-vs1-f49.google.com (mail-vs1-f49.google.com [209.85.217.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8313512001E; Fri, 24 Jan 2020 04:37:48 -0800 (PST) Received: by mail-vs1-f49.google.com with SMTP id b79so1084079vsd.9; Fri, 24 Jan 2020 04:37:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nzRnXLWhwtIr1JMETtW2CWBmM+HOlmmA8+P4a1jXrcw=; b=uXTHeFULwX+appDgT0BrKMnqskWGfXDcK5d4agBaPbZItMpE/c6Bf8Hl9Byv8X9ilP 2g2H2f+mhOgZWnsOtyzY8FrDfRmMA+Fs+P7DrsjIFvmDZBgtOeoJoEFDcZw7xGDMqR6i +kX7C2BjRGRyx0r4JaruqLQ/+BBCXrj3Ccg9CUz3kZR7EzfcnYlfStd0iPLlLe1LzQmT i1fQogCODfcYKUfGPL60P28b4JYy8dKzCWLoYek95C0E0PeUUWTrIH5KRRzFHStl0+o5 5KsV8hDeKBwIgHT84MmR6LZwNxVwwacCvab+HTfE0A8RI8q0uPXRLZlv4fhwIq78nL6P zZgA== X-Gm-Message-State: APjAAAXI7ywYNpVWuGlRREtytAuuwIomTTRrUY/pkYHhLOlhKfkyRbYm VwqhWXUokIVsM2YQLu+iUEEqlvzBjUsMFeC40e1GIkenP32ckQ== X-Google-Smtp-Source: APXvYqx0cgbvSYoiTjCwp95D1gBDrLcRnlSLj1qUB2WJ14vtCui69/bQlZZN55LPe59Cn85kcNFKz8IiAIhOF6gDJrA= X-Received: by 2002:a67:f749:: with SMTP id w9mr2189131vso.69.1579869467362; Fri, 24 Jan 2020 04:37:47 -0800 (PST) MIME-Version: 1.0 References: <1871924156.4933601578025456778.JavaMail.nobody@rva2rmd101.webex.com> In-Reply-To: <1871924156.4933601578025456778.JavaMail.nobody@rva2rmd101.webex.com> From: Daniel Migault Date: Fri, 24 Jan 2020 07:37:36 -0500 Message-ID: To: ace-chairs@ietf.org Cc: Ace Wg Content-Type: multipart/alternative; boundary="00000000000064c794059ce2060f" Archived-At: Subject: Re: [Ace] Webex meeting invitation: ACE interim meeting X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 12:37:51 -0000 --00000000000064c794059ce2060f Content-Type: text/plain; charset="UTF-8" Hi, This is a reminder of the interim meeting next week. By the interim meeting, we would especially appreciate your feed backs on the following documents. * ace-mqtt-profile * ace-key-groupcomm * ace-key-groupcomm-oscore I would also ask the authors to respond to this email with a (short) status update for each WG documents. Especially mentioning how far each document is - in their opinion - from a WGLC. Yours, ACE chairs [1] https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/ [2] https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/ [3] https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm-oscore/ On Thu, Jan 2, 2020 at 11:24 PM ACE Working Group wrote: > > ACE Working Group invites you to join this Webex meeting. > > Meeting number (access code): 641 066 992 > Meeting password: akZaYmff > > Friday, January 31, 2020 > 11:00 am | (UTC-05:00) Eastern Time (US & Canada) | 1 hr 30 mins > > Join meeting > > > *Join by phone* > Tap to call in from a mobile device (attendees only) > 1-650-479-3208 <%2B1-650-479-3208,,*01*641066992%23%23*01*> Call-in toll > number (US/Canada) > > *Join from a video system or application* > Dial 641066992@ietf.webex.com > You can also dial 173.243.2.68 and enter your meeting number. > > *Join using Microsoft Lync or Microsoft Skype for Business* > Dial 641066992.ietf@lync.webex.com > > Need help? Go to http://help.webex.com > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --00000000000064c794059ce2060f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0
This is a reminder of the interim meeting ne= xt week. By the interim=C2=A0meeting, we would=C2=A0especially appreciate y= our feed backs on the following documents.=C2=A0
=C2=A0
* ace-mqtt-profile
* ace-key-groupcomm
* ac= e-key-groupcomm-oscore=C2=A0

<= span lang=3D"EN-GB" style=3D"font-size:11pt;font-family:Calibri,sans-serif"= >I would also ask the authors to respond to this email=C2=A0with a (short) = status update for each WG documents. Especially mentioning how far each doc= ument is - in their opinion - from a WGLC.=C2=A0
=C2=A0<= /span>
Yours,=C2=A0
ACE chairs
<= div>
= =C2=A0

On Thu, Jan 2, 2020 at 11:24 PM ACE Working Group &l= t;messenger@webex.com> wrote:=
=C2=A0
=09
ACE Working Group invites you to join this Webex meeting.
=C2= =A0
Meeting number (access code): 641 066 992
Meeting password: akZaYmff
=20
=C2= =A0
Friday, January 31, 2020
11:00 am=C2=A0=C2=A0|=C2=A0=C2=A0(UTC-05= :00) Eastern Time (US & Canada)=C2=A0=C2=A0|=C2=A0=C2=A01 hr 30 mins
=20
=C2=A0
Join meeting
= =C2=A0
=
Join by phone
Tap to call in from a mobile device (attendees only)
1-650-479-32= 08=C2=A0Call-in toll number (US/Can= ada)
=C2=A0
=
Join from a video system or ap= plication
Dial 641066992@ietf.webex.com
You can also dial 173.243.2.68 and e= nter your meeting number.
=C2=A0
= =
Join using Microsoft Lync or Microsoft Skype for Business
Dial 641066992.ietf@lync.webex.com
=C2=A0
Need help? Go to http:/= /help.webex.com
=C2=A0
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--00000000000064c794059ce2060f-- From nobody Fri Jan 24 08:59:13 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519D1120AA2; Fri, 24 Jan 2020 08:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.93 X-Spam-Level: X-Spam-Status: No, score=-2.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvZvcQFBWa3l; Fri, 24 Jan 2020 08:59:09 -0800 (PST) Received: from smtp01.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 984D6120A9C; Fri, 24 Jan 2020 08:59:09 -0800 (PST) Received: from request4.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp01.icann.org (Postfix) with ESMTP id 644B9E1847; Fri, 24 Jan 2020 16:59:09 +0000 (UTC) Received: by request4.lax.icann.org (Postfix, from userid 48) id 5F93E20441; Fri, 24 Jan 2020 16:59:09 +0000 (UTC) RT-Owner: Nobody From: "Sabrina Tanamal via RT" Reply-To: drafts-lastcall@iana.org In-Reply-To: <20200124014548.GE90660@kduck.mit.edu> References: <9c32d171-9a4a-ba71-c989-92a177d9e989@gmx.de> <77781da882414f4aae98ae2443691933@combitech.se> <582bfd3fbdee4cc592b92857c955721b@combitech.se> <20200124014548.GE90660@kduck.mit.edu> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #1160802 X-Managed-BY: RT 4.4.3 (http://www.bestpractical.com/rt/) X-RT-Originator: sabrina.tanamal@icann.org CC: kaduk@mit.edu, daniel.migault@ericsson.com, ludwig_seitz@gmx.de, rdd@cert.org, ludwig.seitz@combitech.se, jwt-reg-review@ietf.org, ietf@augustcellars.com, bcampbell@pingidentity.com, ace@ietf.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Fri, 24 Jan 2020 16:59:09 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Ace] [IANA #1160802] Re: Requested review for IANA registration in draft-ietf-ace-oauth-params X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 16:59:12 -0000 Hi Ben, Since there are multiple experts for this registry, we can ask the others to review the registration. Thanks, Sabrina Tanamal Senior IANA Services Specialist On Fri Jan 24 01:46:47 2020, kaduk@mit.edu wrote: > Thanks for putting the effort in, Brian. > > IANA, do you need to assign a new expert to reviewi the JWT Claims > registration request from this document, or are the experts expected > to be > self-organizing here? > > Thanks, > > Ben > > On Thu, Jan 23, 2020 at 02:31:20PM -0700, Brian Campbell wrote: > > Apologies, I forgot to reply-all at some earlier point and dropped > > the > > mailing lists and other cc's off the thread. Added back now. > > > > And also apologies because I think I need to recuse myself from the > > DE > > responsibility on the JWT registry request here. I've spent more time > > than > > I'd like to admit or really have to spare on it and am still > > struggling to > > understand. > > > > I appreciate you pointing out the authz-info endpoint in ACE but I > > still > > don't follow how "rs_cnf" in an access token would really work in > > practice. > > The client sends the token to the RS's authz-info endpoint on an > > insecure > > connection or one that has the server auth with potentially different > > key > > and the RS stores the access token for later use. Then on resource > > access > > the RS looks up the access token (with respect to the cnf key in it) > > based > > on the key the client used in establishing a new mutually > > authentication > > connection to the RS. For the RS to choose a key for server it will > > use > > during the handshake (and as far as I know the server key is the > > first in > > the authn process of the handshake) based on the "rs_cnf" in the > > access > > token, it needs to remember and associate that client and the access > > token > > with something else (IP address?) that will be available during the > > handshake. It doesn't fit together for me in a way that seems likely > > to > > work or be interoperable but, like I said, I'm really struggling to > > understand. > > > > On Thu, Jan 16, 2020 at 12:54 AM Seitz Ludwig > > > > wrote: > > > > > Hi Brian, > > > > > > > > > > > > Comments inline. > > > > > > > > > > > > /Ludwig > > > > > > > > > > > > *From:* Brian Campbell > > > *Sent:* den 13 januari 2020 21:22 > > > *To:* Seitz Ludwig > > > *Subject:* Re: [Ace] Requested review for IANA registration in > > > draft-ietf-ace-oauth-params > > > > > > > > > > > > Thanks for the response and updates Ludwig, > > > > > > > > > > > > Please bear with me while I try to wrap my head around some things. > > > > > > > > > > > > The JWT registration request for the "rs_cnf" claim points to Sec > > > 3.3 > > > > > 08#section-3.3> > > > saying it is "a hint [in the access token] to the RS about which > > > key it > > > should use to authenticate towards the client". But doesn't the > > > client > > > have to go through the DTLS/TLS handshake with the RS (which is > > > presumably > > > when it authenticates to the client) before it presents the access > > > token? > > > I'm not seeing how this would work as seems the RS won't see the > > > hint until > > > after it needs it. > > > > > > > > > > > > > > > > > > [LS] Not in the ACE flow. We use the access token to establish keys > > > at the > > > RS both for the client and the RS. We have therefore defined a new > > > ACE-OAuth endpoint (authz-info) at the RS. The client can POST > > > access > > > tokens to this endpoint without prior authentication. > > > > > > At that point, the RS only validates the signature/MAC by the AS. > > > > > > > > > > > > Later at the time of access, the corresponding token is linked to > > > the > > > access request via the pop-mechanism and the client/access specific > > > parts > > > are validated (e.g. scope, subject). > > > > > > > > > > > > Hope that clarifies things a bit. > > > > > > > > > > > > On Sat, Jan 11, 2020 at 8:30 AM Seitz Ludwig > > > > > > wrote: > > > > > > Hello again Brian, > > > > > > > > > > > > Thank you for reviewing this! Indeed the handling of JWT/JSON > > > interactions > > > was handled sloppily here. I will soon issue a draft update that > > > specifies > > > that the JSON-based interactions should use the syntax from RFC7800 > > > while > > > the CBOR-based ones should use ID.ietf-ace-cwt-proof-of-possession. > > > > > > > > > > > > This correction goes for all the use of “cnf”, “req_cnf” and > > > “rs_cnf”. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Ludwig > > > > > > > > > > > > *From:* Ace *On Behalf Of *Brian Campbell > > > *Sent:* den 10 januari 2020 22:12 > > > *To:* Ludwig Seitz > > > *Cc:* Roman Danyliw ; jwt-reg-review@ietf.org; Jim > > > Schaad < > > > ietf@augustcellars.com>; The IESG ; ace@ietf.org; > > > drafts-lastcall@iana.org; Benjamin Kaduk > > > *Subject:* Re: [Ace] Requested review for IANA registration in > > > draft-ietf-ace-oauth-params > > > > > > > > > > > > That "rs_cnf" claim registration request in 9.1 points to 3.3 > > > which says > > > it has 'the same syntax and semantics as defined in for the > > > "rs_cnf" > > > parameter', which I think is in 4.1. And 4.1 says that the "rs_cnf" > > > values > > > 'follow the syntax of the "cnf" claim from section 3.1 of > > > [I-D.ietf-ace-cwt-proof-of-possession].' Similar to other comments > > > I've > > > made today, I don't follow what that would mean for the value of > > > the claim > > > when it's a JWT. And that seems like something that's important to > > > understand for the purpose of a JWT claims registry request. > > > > > > > > > > > > > > > > > > On Sat, Dec 21, 2019 at 4:11 AM Ludwig Seitz > > > wrote: > > > > > > Hello JWT registry reviewers, > > > > > > the IESG-designated experts for the JWT claims registry have asked > > > me to > > > send a review request to you about the "rs_cnf" claim registered > > > here: > > > > > > https://tools.ietf.org/html/draft-ietf-ace-oauth-params-07#section- > > > 9.1 > > > > > > Thank you in advance for you review comments. > > > > > > Regards, > > > > > > Ludwig > > > > > > _______________________________________________ > > > Ace mailing list > > > Ace@ietf.org > > > https://www.ietf.org/mailman/listinfo/ace > > > > > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > > > privileged material for the sole use of the intended recipient(s). > > > Any > > > review, use, distribution or disclosure by others is strictly > > > prohibited.. > > > If you have received this communication in error, please notify the > > > sender > > > immediately by e-mail and delete the message and any file > > > attachments from > > > your computer. Thank you.* > > > > > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > > > privileged material for the sole use of the intended recipient(s). > > > Any > > > review, use, distribution or disclosure by others is strictly > > > prohibited. > > > If you have received this communication in error, please notify the > > > sender > > > immediately by e-mail and delete the message and any file > > > attachments from > > > your computer. Thank you.* > > > > > > > -- > > _CONFIDENTIALITY NOTICE: This email may contain confidential and > > privileged > > material for the sole use of the intended recipient(s). Any review, > > use, > > distribution or disclosure by others is strictly prohibited.  If you > > have > > received this communication in error, please notify the sender > > immediately > > by e-mail and delete the message and any file attachments from your > > computer. Thank you._ From nobody Mon Jan 27 01:38:32 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9A6F120132; Mon, 27 Jan 2020 01:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6B1vDL725vXW; Mon, 27 Jan 2020 01:38:27 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60079.outbound.protection.outlook.com [40.107.6.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFB9A12012E; Mon, 27 Jan 2020 01:38:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L6dlCVRwzSyXt7w4/WQsT++mULs7BcD3pnd8kLUiX1jV5R9t+IyRe4PA5f2N1g+Qbf2BcbyU0OUWY4kWogiQ70rJtJpzXCnAQvUAiydiTyW43c4hL2o0MvcIhdN1JGRB2NH8vVwZ6pM4vrWPsoA2UlQ1LICAv0+6hasrkHpck3yMCJuQMIZF9DNklZDM+eCGMMU0ek1vJLlR8Ojh8Zn+BbFWIIM5zXIDiZ2EOl59dk4xp/4y00CI6TJB+Fis3MhJVxQX71GEPdR71Pax90/Vz0vUOi1b6mBdDP2k09i5NF6vgvIrWk42ZXiTTfmf7RD9kY4iqRWvfSgWt/a1RYPAKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7393SsfGsqWlD6O8k1l6XD/bkPssK/7DaFPqe1xWcrc=; b=eJEt6iX1v6ZAsli/+fN+3zkWM8jnqFvj8yGUNf0GOuGQMNAyM8+ODxBSFCLCP0IflyurIYCHNVQa2NvGpMtNZRZlFiH165EfvQc5O1rsDnlSHiwJ0rwLyXInFzmv7fuQm0+t2LCTpzH1d6gTf4UQZLjg5vODT4YxJgInkfo0Xd3rxixcFXQ0bQ5nzhkAS+x4g4orIb/FjDVYtHf00aJiq/6RnKY6mtpcrSPdjAGjvKglOog1qk04lWgf0q+RSWIxQqcMG1SZwSwgq67E/9E7CwcGLBDAlzcVS/DhkbQfwRLV2JD20k7xxVeYw7BjyZ4U5t3MSP5K0v4O0KePIsd1gA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7393SsfGsqWlD6O8k1l6XD/bkPssK/7DaFPqe1xWcrc=; b=qGdeRkklWUktMzS7S6zzSi6QuqueTvbB8dK4dAgLEuo7AIjnx67H1G1y9XRnzHKGk24NxnE9/DsGTurv8vlxZJvmLVPh9F0mO0y+wTFe6DhDcAE7T+XN29qfUsJrm6rt8ejmLcbXntm2jana/a174i4cg7ewLJHei2psVnlvsRE= Received: from AM6PR07MB4053.eurprd07.prod.outlook.com (52.134.117.139) by AM6PR07MB5859.eurprd07.prod.outlook.com (20.177.189.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.18; Mon, 27 Jan 2020 09:38:24 +0000 Received: from AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::7537:e135:422d:c5a7]) by AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::7537:e135:422d:c5a7%5]) with mapi id 15.20.2686.019; Mon, 27 Jan 2020 09:38:24 +0000 From: Francesca Palombini To: Daniel Migault , "ace-chairs@ietf.org" CC: Ace Wg Thread-Topic: [Ace] Webex meeting invitation: ACE interim meeting Thread-Index: AQHVwe23A2wlVTM61EmtGIxEUc/HfKf54kEAgASVr4A= Date: Mon, 27 Jan 2020 09:38:24 +0000 Message-ID: <174DC95A-EEA1-4E57-9C65-7FAC73F0C87B@ericsson.com> References: <1871924156.4933601578025456778.JavaMail.nobody@rva2rmd101.webex.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b02ecdfc-6f7b-4c3e-9a02-08d7a30ca79c x-ms-traffictypediagnostic: AM6PR07MB5859: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4125; x-forefront-prvs: 02951C14DC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(39860400002)(136003)(396003)(376002)(189003)(199004)(81156014)(8676002)(36756003)(81166006)(316002)(26005)(6506007)(53546011)(6486002)(186003)(8936002)(86362001)(9326002)(33656002)(91956017)(4326008)(19627405001)(2906002)(66476007)(66556008)(64756008)(66446008)(71200400001)(66946007)(76116006)(5660300002)(6512007)(16799955002)(2616005)(478600001)(44832011)(966005)(110136005)(45080400002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB5859; H:AM6PR07MB4053.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: y+nu0dAJ3QeeH873KzwtfpZ8qxdh48FsWipCefAVaIsyIG9i04U9hXiX5bk5ag3vbj0AKYTdBEY7euQGAPjClWak79Y3+vY9XVFmyvSJ9Bvj1ebou9Eahfks3yB+NRR4DOvhU2KPDUeMa6pi9WX9waCEt7dMRpFOZkadJ7qFNeLA5N5uERoSt25frGy8xy4OI6C/uE7mFidcnlSUPjNKaRxDNSp1K9B91deXDO7/0flqY94KR5a2X/v/CZlHucseRGjMPnheH0vvfhBUfDGcKcM12mrz3qUUI5ATfRXD9ZBdxoTXiF8iE9NM4Kr4INMTvkVN7Ikk9rng1EeLpepxW7ln1LXNPF5x/qPDiqRT+aOS4GO5y4iPwqr2e97qWG0pqUrd/WAwEHZWeKr2PzRUto6BgPGiEwsU7lVqUc2GOTMzGAvQp14JsxqFqmYuCQAhvkvKhrjBAXxjNHU9af2BVR0X1OUCYsXfPgBp9ag9W+mJlS1mz4Jt9Dp1gKZLuB1HZb/b3t4VxLTI11LNjwTJ/Q== x-ms-exchange-antispam-messagedata: gbcRrL+BGDKq4VbUyoQBZZ7EWlvSXuQIRLwq3u/yKXlpFuJXvm07af+qhYxv3UTA107CtwfN67e8SMVhEUCadz9olXkquz/QcTTbpryeqXrljNmeN4jQ3cbWe25BGSOI1F3p+2Mk0AZYMVjQXBrPEA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_174DC95AEEA14E579C657FAC73F0C87Bericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: b02ecdfc-6f7b-4c3e-9a02-08d7a30ca79c X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2020 09:38:24.2638 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vOeY/0NnvVjJcS1s6BUsGgjX9RxE3gb1lnRe3LN3ZkdMuo4ODpGRunyNRbXNRTPzJ+PyZHg4j2IHxBD8F4EoMGaLF/5YZP4FjMp6fqpVSCf9iQw7/5H1Zumwd7cq886U X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5859 Archived-At: Subject: Re: [Ace] Webex meeting invitation: ACE interim meeting X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2020 09:38:31 -0000 --_000_174DC95AEEA14E579C657FAC73F0C87Bericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClJlOiBzdGF0dXMgdXBkYXRlIGFjZS1rZXktZ3JvdXBjb21tOg0KDQpUaGUgZG9jdW1l bnQgaGFzIGJlZW4gdXBkYXRlZCB0byB2LTA0IGluIHByZXBhcmF0aW9uIGZvciBuZXh0IHdlZWsg aW50ZXJpbS4gVGhlIHVwZGF0ZSBjb3ZlcnMgYWxtb3N0IGFsbCByZXZpZXcgY29tbWVudHMgcmVj ZWl2ZWQsIGluY2x1ZGluZyB3aGF0IGRpc2N1c3NlZCBhdCBJRVRGMTA2Lg0KDQpGcm9tOiBBY2Ug PGFjZS1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgRGFuaWVsIE1pZ2F1bHQgPGRhbmll bC5taWdhdWx0PTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnPg0KRGF0ZTogRnJpZGF5LCAy NCBKYW51YXJ5IDIwMjAgYXQgMTM6MzgNClRvOiAiYWNlLWNoYWlyc0BpZXRmLm9yZyIgPGFjZS1j aGFpcnNAaWV0Zi5vcmc+DQpDYzogQWNlIFdnIDxhY2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog W0FjZV0gV2ViZXggbWVldGluZyBpbnZpdGF0aW9uOiBBQ0UgaW50ZXJpbSBtZWV0aW5nDQoNCkhp LA0KVGhpcyBpcyBhIHJlbWluZGVyIG9mIHRoZSBpbnRlcmltIG1lZXRpbmcgbmV4dCB3ZWVrLiBC eSB0aGUgaW50ZXJpbSBtZWV0aW5nLCB3ZSB3b3VsZCBlc3BlY2lhbGx5IGFwcHJlY2lhdGUgeW91 ciBmZWVkIGJhY2tzIG9uIHRoZSBmb2xsb3dpbmcgZG9jdW1lbnRzLg0KDQoqIGFjZS1tcXR0LXBy b2ZpbGUNCiogYWNlLWtleS1ncm91cGNvbW0NCiogYWNlLWtleS1ncm91cGNvbW0tb3Njb3JlDQoN Ckkgd291bGQgYWxzbyBhc2sgdGhlIGF1dGhvcnMgdG8gcmVzcG9uZCB0byB0aGlzIGVtYWlsIHdp dGggYSAoc2hvcnQpIHN0YXR1cyB1cGRhdGUgZm9yIGVhY2ggV0cgZG9jdW1lbnRzLiBFc3BlY2lh bGx5IG1lbnRpb25pbmcgaG93IGZhciBlYWNoIGRvY3VtZW50IGlzIC0gaW4gdGhlaXIgb3Bpbmlv biAtIGZyb20gYSBXR0xDLg0KDQpZb3VycywNCkFDRSBjaGFpcnMNCg0KWzFdIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYWNlLW1xdHQtdGxzLXByb2ZpbGUvDQpb Ml0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1hY2Uta2V5LWdy b3VwY29tbS8NClszXSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LWFjZS1rZXktZ3JvdXBjb21tLW9zY29yZS8NCg0KDQpPbiBUaHUsIEphbiAyLCAyMDIwIGF0IDEx OjI0IFBNIEFDRSBXb3JraW5nIEdyb3VwIDxtZXNzZW5nZXJAd2ViZXguY29tPG1haWx0bzptZXNz ZW5nZXJAd2ViZXguY29tPj4gd3JvdGU6DQoNCkFDRSBXb3JraW5nIEdyb3VwIGludml0ZXMgeW91 IHRvIGpvaW4gdGhpcyBXZWJleCBtZWV0aW5nLg0KDQoNCg0KTWVldGluZyBudW1iZXIgKGFjY2Vz cyBjb2RlKTogNjQxIDA2NiA5OTINCg0KTWVldGluZyBwYXNzd29yZDogYWtaYVltZmYNCg0KDQoN CkZyaWRheSwgSmFudWFyeSAzMSwgMjAyMA0KMTE6MDAgYW0gIHwgIChVVEMtMDU6MDApIEVhc3Rl cm4gVGltZSAoVVMgJiBDYW5hZGEpICB8ICAxIGhyIDMwIG1pbnMNCg0KDQoNCkpvaW4gbWVldGlu ZzxodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tODhmZjM2Y2NhYjM4YjVl MDY1ZTc4NjVjMDRiYmIyNDA+DQoNCg0KDQpKb2luIGJ5IHBob25lDQpUYXAgdG8gY2FsbCBpbiBm cm9tIGEgbW9iaWxlIGRldmljZSAoYXR0ZW5kZWVzIG9ubHkpDQoxLTY1MC00NzktMzIwODx0ZWw6 JTJCMS02NTAtNDc5LTMyMDgsLCowMSo2NDEwNjY5OTIlMjMlMjMqMDEqPiBDYWxsLWluIHRvbGwg bnVtYmVyIChVUy9DYW5hZGEpDQoNCg0KDQpKb2luIGZyb20gYSB2aWRlbyBzeXN0ZW0gb3IgYXBw bGljYXRpb24NCkRpYWwgNjQxMDY2OTkyQGlldGYud2ViZXguY29tDQpZb3UgY2FuIGFsc28gZGlh bCAxNzMuMjQzLjIuNjggYW5kIGVudGVyIHlvdXIgbWVldGluZyBudW1iZXIuDQoNCg0KDQpKb2lu IHVzaW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1pY3Jvc29mdCBTa3lwZSBmb3IgQnVzaW5lc3MNCkRp YWwgNjQxMDY2OTkyLmlldGZAbHluYy53ZWJleC5jb20NCg0KTmVlZCBoZWxwPyBHbyB0byBodHRw Oi8vaGVscC53ZWJleC5jb20NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCkFjZSBtYWlsaW5nIGxpc3QNCkFjZUBpZXRmLm9yZzxtYWlsdG86QWNlQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCg== --_000_174DC95AEEA14E579C657FAC73F0C87Bericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <127BE1C04F46B546B6E3F0EA84486BB9@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0Ii IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPlJlOiBzdGF0dXMgdXBkYXRlIGFjZS1rZXktZ3JvdXBjb21tOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5UaGUgZG9jdW1lbnQgaGFzIGJlZW4gdXBkYXRlZCB0byB2LTA0IGluIHByZXBhcmF0aW9uIGZv ciBuZXh0IHdlZWsgaW50ZXJpbS4gVGhlIHVwZGF0ZSBjb3ZlcnMgYWxtb3N0IGFsbCByZXZpZXcg Y29tbWVudHMgcmVjZWl2ZWQsIGluY2x1ZGluZyB3aGF0IGRpc2N1c3NlZCBhdCBJRVRGMTA2Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkFjZSAmbHQ7YWNlLWJvdW5j ZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBEYW5pZWwgTWlnYXVsdCAmbHQ7ZGFuaWVsLm1p Z2F1bHQ9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9i PkZyaWRheSwgMjQgSmFudWFyeSAyMDIwIGF0IDEzOjM4PGJyPg0KPGI+VG86IDwvYj4mcXVvdDth Y2UtY2hhaXJzQGlldGYub3JnJnF1b3Q7ICZsdDthY2UtY2hhaXJzQGlldGYub3JnJmd0Ozxicj4N CjxiPkNjOiA8L2I+QWNlIFdnICZsdDthY2VAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDog PC9iPlJlOiBbQWNlXSBXZWJleCBtZWV0aW5nIGludml0YXRpb246IEFDRSBpbnRlcmltIG1lZXRp bmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhpLCZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGlzIGlzIGEgcmVtaW5kZXIgb2YgdGhlIGludGVyaW0gbWVldGluZyBuZXh0IHdlZWsu IEJ5IHRoZSBpbnRlcmltJm5ic3A7bWVldGluZywgd2Ugd291bGQmbmJzcDtlc3BlY2lhbGx5IGFw cHJlY2lhdGUgeW91ciBmZWVkIGJhY2tzIG9uIHRoZSBmb2xsb3dpbmcgZG9jdW1lbnRzLiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4q IGFjZS1tcXR0LXByb2ZpbGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiogYWNlLWtleS1ncm91cGNvbW08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiogYWNlLWtleS1ncm91cGNvbW0tb3Njb3JlJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pkkgd291bGQgYWxzbyBhc2sgdGhlIGF1dGhvcnMgdG8gcmVzcG9uZCB0byB0aGlzIGVtYWlsJm5i c3A7d2l0aCBhIChzaG9ydCkgc3RhdHVzIHVwZGF0ZSBmb3IgZWFjaCBXRyBkb2N1bWVudHMuIEVz cGVjaWFsbHkgbWVudGlvbmluZyBob3cgZmFyIGVhY2ggZG9jdW1lbnQgaXMgLSBpbiB0aGVpciBv cGluaW9uIC0gZnJvbSBhIFdHTEMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdXJzLCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QUNFIGNoYWlyczxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bMV0mbmJzcDs8YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWFjZS1tcXR0LXRs cy1wcm9maWxlLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1h Y2UtbXF0dC10bHMtcHJvZmlsZS88L2E+Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bMl0mbmJzcDs8YSBocmVmPSJodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWFjZS1rZXktZ3JvdXBjb21tLyI+ aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1hY2Uta2V5LWdyb3Vw Y29tbS88L2E+Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5bM10mbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLWFjZS1rZXktZ3JvdXBjb21tLW9zY29yZS8iPmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYWNlLWtleS1ncm91cGNvbW0tb3Nj b3JlLzwvYT4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBUaHUsIEphbiAyLCAyMDIwIGF0IDExOjI0IFBNIEFDRSBXb3JraW5n IEdyb3VwICZsdDs8YSBocmVmPSJtYWlsdG86bWVzc2VuZ2VyQHdlYmV4LmNvbSI+bWVzc2VuZ2Vy QHdlYmV4LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow Y20iPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGlu Zz0iMCIgYWxpZ249ImxlZnQiIHdpZHRoPSIxMDAlIiBzdHlsZT0id2lkdGg6MTAwLjAlO2JhY2tn cm91bmQ6d2hpdGUiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MjEuMHB0Ij4NCjx0ZCBz dHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY207aGVpZ2h0OjIxLjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNw YWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVy dGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28t aGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3Ry Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAxNS4wcHQgMGNtIDE1LjBwdCI+DQo8dGFi bGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCjx0 Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE2LjVwdCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1 cHQgLjc1cHQgLjc1cHQgLjc1cHQ7aGVpZ2h0OjE2LjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTYuNXB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50 LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQt YW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpj b2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+QUNFIFdvcmtpbmcgR3JvdXAgaW52aXRlcyB5b3UgdG8gam9pbiB0aGlzIFdlYmV4IG1l ZXRpbmcuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5 Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tZWxlbWVudDpmcmFt ZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5k O21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9y LWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxl PSJkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFz cz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0K PHRyIHN0eWxlPSJoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVw dCAuNzVwdCAuNzVwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUt aHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3It dmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjtt c28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8 L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVu dC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1l bGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+ DQo8c3BhbiBzdHlsZT0iZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIw IiB3aWR0aD0iMCIgc3R5bGU9IndpZHRoOjBjbSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9 InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImxpbmUtaGVpZ2h0OjE2LjVwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1m cmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFu Y2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29s dW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si Pk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDY0MSAwNjYgOTkyDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFj ZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRp Y2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhl aWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImRpc3BsYXk6bm9uZSI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVy PSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjAiIHN0eWxlPSJ3aWR0aDowY20iPg0KPHRib2R5 Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNi41cHQ7bXNvLWVsZW1lbnQ6 ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFy b3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFu Y2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj5NZWV0aW5nIHBhc3N3b3JkOiBha1phWW1mZjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNw YWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVy dGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28t aGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZGlzcGxheTpub25lIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3Jk ZXI9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBw dCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQ7aGVpZ2h0OjE1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21z by1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1l bnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28t ZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHki Pg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVt ZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1l bnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRh bDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImRpc3BsYXk6 bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3Jt YWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjEwMCUiIHN0eWxlPSJ3 aWR0aDoxMDAuMCUiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43 NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdo dDoxNi41cHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVw dDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFy YWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1 bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPkZyaWRheSwgSmFudWFy eSAzMSwgMjAyMA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8 dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE2LjVwdDttc28tZWxlbWVudDpmcmFtZTttc28t ZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1l bGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6 b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzY2NjY2NiI+MTE6MDAgYW0mbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7KFVUQy0wNTowMCkg RWFzdGVybiBUaW1lIChVUyAmYW1wOyBDYW5hZGEpJm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNwOzEg aHIgMzAgbWlucw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5 Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tZWxlbWVudDpmcmFt ZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5k O21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9y LWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxl PSJkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFz cz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0K PHRyIHN0eWxlPSJoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVw dCAzLjBwdCAuNzVwdDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUt aHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3It dmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjtt c28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90 ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1l bGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7 bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFj dGx5Ij4NCjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJs ZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjAiIHN0eWxlPSJ3aWR0aDowY207 Ym9yZGVyLXJhZGl1czoyMHB4O21pbi13aWR0aDoxNjBweCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQg d2lkdGg9IjAiIHN0eWxlPSJ3aWR0aDouM3B0O3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1 cHQiPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIxIiBjZWxsc3BhY2lu Zz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIwIiBzdHlsZT0id2lkdGg6MGNtO2JhY2tncm91 bmQ6IzQzQTk0Mjtib3JkZXI6c29saWQgIzQzQTk0MiAxLjBwdCI+DQo8dGJvZHk+DQo8dHI+DQo8 dGQgc3R5bGU9ImJvcmRlcjpub25lO3BhZGRpbmc6Ny41cHQgMjcuMHB0IDcuNXB0IDI3LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpj ZW50ZXI7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDtt c28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdy YXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6 ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRm L2oucGhwP01USUQ9bTg4ZmYzNmNjYWIzOGI1ZTA2NWU3ODY1YzA0YmJiMjQwIiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Y29sb3I6d2hpdGU7dGV4dC1kZWNv cmF0aW9uOm5vbmUiPkpvaW4gbWVldGluZzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC90ZD4NCjwvdHI+DQo8 L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tZWxlbWVu dDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6 YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQt YW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFu IHN0eWxlPSJkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJs ZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KPHRi b2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MzYuMHB0Ij4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVw dCAuNzVwdCAuNzVwdCAuNzVwdDtoZWlnaHQ6MzYuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJsaW5lLWhlaWdodDozNi4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQt ZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1h bmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNv bHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv dGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28t ZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBo O21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhh Y3RseSI+DQo8c3BhbiBzdHlsZT0iZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRk aW5nPSIwIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAu NzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTgu MHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNv LWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFw aDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4 YWN0bHkiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Kb2luIGJ5IHBob25lPG86cD48 L286cD48L3NwYW4+PC9iPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRk aW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxOC4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUt aHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3It dmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjtt c28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk5OTk5OSI+VGFw IHRvIGNhbGwgaW4gZnJvbSBhIG1vYmlsZSBkZXZpY2UgKGF0dGVuZGVlcyBvbmx5KTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43 NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5l LWhlaWdodDoxOC4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNl OjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGlj YWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVp Z2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPjxhIGhyZWY9 InRlbDolMkIxLTY1MC00NzktMzIwOCwsKjAxKjY0MTA2Njk5MiUyMyUyMyowMSoiIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwQUZGOTt0ZXh0LWRlY29yYXRpb246bm9uZSI+ MS02NTAtNDc5LTMyMDg8L3NwYW4+PC9hPiZuYnNwO0NhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0Nh bmFkYSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHls ZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+PC90ZD4NCjwvdHI+DQo8L3Rib2R5 Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tZWxlbWVudDpmcmFt ZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5k O21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9y LWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxl PSJkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFz cz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5n PSIwIj4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjIxLjBwdCI+DQo8dGQgc3R5bGU9InBh ZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDoyMS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjIxLjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVu dC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50 LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6 Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21z by1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3Jh cGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpl eGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBh ZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0 IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDox OC4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDtt c28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdy YXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6 ZXhhY3RseSI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkpvaW4gZnJvbSBhIHZpZGVv IHN5c3RlbSBvciBhcHBsaWNhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8L3RkPg0K PC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTguMHB0O21zby1lbGVt ZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3Jh cDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVu dC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMzMzMzMzIj5EaWFsIDY0MTA2Njk5MkBpZXRmLndlYmV4LmNvbTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRk aW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxOC4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUt aHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3It dmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjtt c28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPllv dSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42OCBhbmQgZW50ZXIgeW91ciBtZWV0aW5nIG51bWJl ci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVt ZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1l bnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRh bDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImRpc3BsYXk6 bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3Jt YWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9 ImhlaWdodDoxNS4wcHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43 NXB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVp Z2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4y NXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpw YXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQt cnVsZTpleGFjdGx5Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Ri b2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tZWxlbWVudDpm cmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJv dW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5j aG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0 eWxlPSJkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBj bGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRk aW5nPSIwIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE4LjBwdDttc28t ZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50 LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVs ZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4N CjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Sm9pbiB1c2luZyBNaWNyb3NvZnQgTHluYyBv ciBNaWNyb3NvZnQgU2t5cGUgZm9yIEJ1c2luZXNzPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4N CjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTguMHB0O21zby1lbGVt ZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3Jh cDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVu dC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMzMzMzMzIj5EaWFsIDY0MTA2Njk5Mi5pZXRmQGx5bmMud2ViZXgu Y29tPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJs ZT4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9 IjAiIGFsaWduPSJsZWZ0IiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJv ZHk+DQo8dHIgc3R5bGU9ImhlaWdodDo1NC4wcHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0 IC43NXB0IC43NXB0IC43NXB0O2hlaWdodDo1NC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7 bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFn cmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxl OmV4YWN0bHkiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0ciBzdHls ZT0iaGVpZ2h0OjE4LjBwdCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQg Ljc1cHQ7aGVpZ2h0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1o ZWlnaHQ6MTguMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToy LjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2Fs OnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdo dC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+TmVlZCBoZWxwPyBH byB0bw0KPGEgaHJlZj0iaHR0cDovL2hlbHAud2ViZXguY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImNvbG9yOiMwNDlGRDk7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHA6Ly9oZWxw LndlYmV4LmNvbTwvc3Bhbj48L2E+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90 cj4NCjx0ciBzdHlsZT0iaGVpZ2h0OjMzLjBwdCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQg Ljc1cHQgLjc1cHQgLjc1cHQ7aGVpZ2h0OjMzLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDtt c28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdy YXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6 ZXhhY3RseSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4N CjwvdGFibGU+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpBY2UgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkFjZUBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPkFjZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_174DC95AEEA14E579C657FAC73F0C87Bericssoncom_-- From nobody Mon Jan 27 01:41:28 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A30EA12012D; Mon, 27 Jan 2020 01:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAnXZnrOiCnY; Mon, 27 Jan 2020 01:41:24 -0800 (PST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2060.outbound.protection.outlook.com [40.107.20.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2C8E12001B; Mon, 27 Jan 2020 01:41:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BZ8aIumyDFP5WcNTRvZJ5CcdpwN8LTsKmjGEtdKY3SBJit1NBP7sKTSH8ttD1jxuNx9Gq1qUjGoUiFUJszU9DxMQXa0mL9gCug+CvZ9OQvWjUQFW3wSVFjTWGjp2rAl46GoWkvv1PbeHIuhRmqLncnbSb1aRWQslnXc/okzbgMqFHZWtsFXtisV5+0nmvU/19icagiifyYnA7GIXDaqpyn+DNRSNcX3Bx7T4iLr/LjwpqTJ/o4iz2kAi+Co+6jfKahcLgvM0XmKCYeCzVQBksUBnVaREgBZMvJI2pJNffUb8+HaYtcEgccVZz3/bTSivmo8cjownl4JlWMdL0z1XNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MrLEmyX6iN6J+Wfbg8jUthuQORZVtagpD+AgruHb6a0=; b=P5MuCWz50Sc1B+IGR0kLltYOdbnQhquPNSI/yzr1w95EkU6E5hCpCVcuFlEcMQKtyMk378DZ8vIW7LCTtusPUQkCoVwr8tYF68vs408VGkukDGlwERbFjU09Amuzi8yCocEhJoRnX1ePAt9EUrG4l3m+ZHzx1T/PEsI2BGpoBsxzvvVVT0qmaOMKhgfOWMfIQIj+cFLFE/0Pe0LtPvz6PvTfxXEYn4GtYYq4sKEPkgjYnq7uyx+OLq2NgVIchQzsDRZV9PT5pLsp82cOq3wCHwSneNa/4yfI2QSWYdjxs5d/XllLVDuhk8VF4rokoNLRmmrL7REc1fQWlrNVHdTQdA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MrLEmyX6iN6J+Wfbg8jUthuQORZVtagpD+AgruHb6a0=; b=p6Qz0eLqdwWWNb1A7oTP1k1qu6W7ZifzmSHJ9DMOzN42WF8BdKpgLn0GlG01qeoyan5NAyIAGlRbX3BgYLlQ83Wqm4wFG2zEosMaAnV3iKk2vC4amyfK7EH828tOFz/ujNB8poH89QUqlY3crMHBLM7hc6UH8yM7vDBfOplD/zI= Received: from AM6PR07MB4053.eurprd07.prod.outlook.com (52.134.117.139) by AM6PR07MB4104.eurprd07.prod.outlook.com (52.134.116.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.12; Mon, 27 Jan 2020 09:41:21 +0000 Received: from AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::7537:e135:422d:c5a7]) by AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::7537:e135:422d:c5a7%5]) with mapi id 15.20.2686.019; Mon, 27 Jan 2020 09:41:21 +0000 From: Francesca Palombini To: "ace-chairs@ietf.org" , Ace Wg CC: Daniel Migault Thread-Topic: [Ace] Webex meeting invitation: ACE interim meeting Thread-Index: AQHVwe23A2wlVTM61EmtGIxEUc/HfKf54kEAgASVr4CAAADVgA== Date: Mon, 27 Jan 2020 09:41:21 +0000 Message-ID: <4F6D9FFF-82B5-41C1-B6D6-CD0EB8BD5F53@ericsson.com> References: <1871924156.4933601578025456778.JavaMail.nobody@rva2rmd101.webex.com> <174DC95A-EEA1-4E57-9C65-7FAC73F0C87B@ericsson.com> In-Reply-To: <174DC95A-EEA1-4E57-9C65-7FAC73F0C87B@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e1c9a0f8-ae81-4880-8ab3-08d7a30d113a x-ms-traffictypediagnostic: AM6PR07MB4104: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 02951C14DC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(376002)(366004)(346002)(396003)(189003)(199004)(81156014)(81166006)(316002)(36756003)(110136005)(53546011)(8676002)(8936002)(6506007)(33656002)(86362001)(2616005)(44832011)(71200400001)(186003)(64756008)(26005)(16799955002)(66446008)(5660300002)(4326008)(6512007)(478600001)(2906002)(66946007)(45080400002)(91956017)(76116006)(66476007)(66556008)(966005)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB4104; H:AM6PR07MB4053.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HnbTIeaxMvRcjCzE8TX37iSfOZWRFJ9xZso5GqB65Si4cjD+/t51OuHai60qThBfncF55YrttNwZRJe+LQ+q8w+kRA2LEKinQ/oCd5eUNXiTnw7zb0gg4nAxFgkavXuYU7DdqB1E6hb5mAM+Zn3EcJKh070MMJqQuQSJko+7P+ws97xJIlKO7NGBZnJjkkPGWsDJBxl7kezLkb2ugbbgr1jbJ5EdsXkXlIBqFS+Zm4H7tGd6+cvA+1Ga286XB59d+YiLKE2D7iLLg4XTFUwgbzfL+mLzzIyGvb0LRo1rLqNn+RvKTnwd5QgcepWfZBLsIbsRi09mc+kuW2J2UoPdR5nQSHMbAze0AFDsV0M4o75NgTs0Vg/rMwVTznu1kUmqNmymvkK5q1ROZA3Pkh3cLY+qVAmK02IHy/w8SSkuSbR0jYpa2kuka0kJMokiaCRbLPUh1XBPbBMvGV/yqIEnPoXZtLaDXcF4DQHHsPkxV+Wmhln3zcA7kJds9xlquUKIuWintPifJtrW1yRM6tKPYQ== x-ms-exchange-antispam-messagedata: hKvWi4FZk3V/L0/o1Oz5TQ0QFwcXXUtJm3PHdDWIYWFqjQNhicBVF3rhq8NihJ2ldwHwTte6pndW5Q75AI1tgbVTqjwiqb+GWvczZcNXgoN5m5D2tR67n27KYnZ0K3+vcTHGhHRve1aHi+DaRqNT1w== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_4F6D9FFF82B541C1B6D6CD0EB8BD5F53ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: e1c9a0f8-ae81-4880-8ab3-08d7a30d113a X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2020 09:41:21.4226 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Oh+6SG5p2+QNHXi5IgO+uaxbkSSWlDZ1AroZRoc2OIG9iYTEeqJpd4l6E/dcsBZl75EJNZa2C2sAuylPCkxy2A9N5JZhNa3u7+YuVfLz9ivvPFZDEpwD6pbpbuGDp4ju X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB4104 Archived-At: Subject: Re: [Ace] Webex meeting invitation: ACE interim meeting X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2020 09:41:27 -0000 --_000_4F6D9FFF82B541C1B6D6CD0EB8BD5F53ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29ycnksIHNlbnQgdG9vIGVhcmx5Lg0KDQpUaGUgZGV0YWlscyBhYm91dCB0aGUgdXBkYXRlIHdp bGwgYmUgY292ZXJlZCBpbiB0aGUgc2xpZGVzIGZvciB0aGUgaW50ZXJpbSAoc29vbiB0byBiZSBz ZW50IHRvIGNoYWlycyBmb3IgdXBsb2FkKS4NCkxlZnQgdG8gZG86IGluY2x1ZGUgdGhlIHJldmll dyBjb21tZW50cyBsZWZ0IGZyb20gUGV0ZXIgYW5kIGRpc2N1c3MgYSBmZXcgb3BlbiBpc3N1ZXMs IHdoaWNoIGFyZSBhbnl3YXlzIHN0cmFpZ2h0Zm9yd2FyZCB0byBpbXBsZW1lbnQgb25jZSB0aGUg d2cgaGFzIGRlY2lkZWQuIE9uY2UgdGhlc2UgYXJlIGRvbmUsIHdoaWNoIHdlIHRoaW5rIGNvdWxk IHRha2UgYSBjb3VwbGUgb2Ygc3VibWlzc2lvbnMsIGlmIHdlIGRvbuKAmXQgZ2V0IGFueSBuZWdh dGl2ZSBmZWVkYmFjayB3ZSBjb3VsZCBnbyBmb3IgV0dMQy4NCg0KVGhhbmtzLA0KRnJhbmNlc2Nh DQoNCg0KRnJvbTogQWNlIDxhY2UtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEZyYW5j ZXNjYSBQYWxvbWJpbmkgPGZyYW5jZXNjYS5wYWxvbWJpbmk9NDBlcmljc3Nvbi5jb21AZG1hcmMu aWV0Zi5vcmc+DQpEYXRlOiBNb25kYXksIDI3IEphbnVhcnkgMjAyMCBhdCAxMDozOA0KVG86IERh bmllbCBNaWdhdWx0IDxkYW5pZWwubWlnYXVsdD00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9y Zz4sICJhY2UtY2hhaXJzQGlldGYub3JnIiA8YWNlLWNoYWlyc0BpZXRmLm9yZz4NCkNjOiBBY2Ug V2cgPGFjZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQWNlXSBXZWJleCBtZWV0aW5nIGludml0 YXRpb246IEFDRSBpbnRlcmltIG1lZXRpbmcNCg0KSGksDQoNClJlOiBzdGF0dXMgdXBkYXRlIGFj ZS1rZXktZ3JvdXBjb21tOg0KDQpUaGUgZG9jdW1lbnQgaGFzIGJlZW4gdXBkYXRlZCB0byB2LTA0 IGluIHByZXBhcmF0aW9uIGZvciBuZXh0IHdlZWsgaW50ZXJpbS4gVGhlIHVwZGF0ZSBjb3ZlcnMg YWxtb3N0IGFsbCByZXZpZXcgY29tbWVudHMgcmVjZWl2ZWQsIGluY2x1ZGluZyB3aGF0IGRpc2N1 c3NlZCBhdCBJRVRGMTA2Lg0KDQpGcm9tOiBBY2UgPGFjZS1ib3VuY2VzQGlldGYub3JnPiBvbiBi ZWhhbGYgb2YgRGFuaWVsIE1pZ2F1bHQgPGRhbmllbC5taWdhdWx0PTQwZXJpY3Nzb24uY29tQGRt YXJjLmlldGYub3JnPg0KRGF0ZTogRnJpZGF5LCAyNCBKYW51YXJ5IDIwMjAgYXQgMTM6MzgNClRv OiAiYWNlLWNoYWlyc0BpZXRmLm9yZyIgPGFjZS1jaGFpcnNAaWV0Zi5vcmc+DQpDYzogQWNlIFdn IDxhY2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0FjZV0gV2ViZXggbWVldGluZyBpbnZpdGF0 aW9uOiBBQ0UgaW50ZXJpbSBtZWV0aW5nDQoNCkhpLA0KVGhpcyBpcyBhIHJlbWluZGVyIG9mIHRo ZSBpbnRlcmltIG1lZXRpbmcgbmV4dCB3ZWVrLiBCeSB0aGUgaW50ZXJpbSBtZWV0aW5nLCB3ZSB3 b3VsZCBlc3BlY2lhbGx5IGFwcHJlY2lhdGUgeW91ciBmZWVkIGJhY2tzIG9uIHRoZSBmb2xsb3dp bmcgZG9jdW1lbnRzLg0KDQoqIGFjZS1tcXR0LXByb2ZpbGUNCiogYWNlLWtleS1ncm91cGNvbW0N CiogYWNlLWtleS1ncm91cGNvbW0tb3Njb3JlDQoNCkkgd291bGQgYWxzbyBhc2sgdGhlIGF1dGhv cnMgdG8gcmVzcG9uZCB0byB0aGlzIGVtYWlsIHdpdGggYSAoc2hvcnQpIHN0YXR1cyB1cGRhdGUg Zm9yIGVhY2ggV0cgZG9jdW1lbnRzLiBFc3BlY2lhbGx5IG1lbnRpb25pbmcgaG93IGZhciBlYWNo IGRvY3VtZW50IGlzIC0gaW4gdGhlaXIgb3BpbmlvbiAtIGZyb20gYSBXR0xDLg0KDQpZb3VycywN CkFDRSBjaGFpcnMNCg0KWzFdIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtYWNlLW1xdHQtdGxzLXByb2ZpbGUvDQpbMl0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1hY2Uta2V5LWdyb3VwY29tbS8NClszXSBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWFjZS1rZXktZ3JvdXBjb21tLW9zY29yZS8N Cg0KDQpPbiBUaHUsIEphbiAyLCAyMDIwIGF0IDExOjI0IFBNIEFDRSBXb3JraW5nIEdyb3VwIDxt ZXNzZW5nZXJAd2ViZXguY29tPG1haWx0bzptZXNzZW5nZXJAd2ViZXguY29tPj4gd3JvdGU6DQoN CkFDRSBXb3JraW5nIEdyb3VwIGludml0ZXMgeW91IHRvIGpvaW4gdGhpcyBXZWJleCBtZWV0aW5n Lg0KDQoNCg0KTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogNjQxIDA2NiA5OTINCg0KTWVl dGluZyBwYXNzd29yZDogYWtaYVltZmYNCg0KDQoNCkZyaWRheSwgSmFudWFyeSAzMSwgMjAyMA0K MTE6MDAgYW0gIHwgIChVVEMtMDU6MDApIEVhc3Rlcm4gVGltZSAoVVMgJiBDYW5hZGEpICB8ICAx IGhyIDMwIG1pbnMNCg0KDQoNCkpvaW4gbWVldGluZzxodHRwczovL2lldGYud2ViZXguY29tL2ll dGYvai5waHA/TVRJRD1tODhmZjM2Y2NhYjM4YjVlMDY1ZTc4NjVjMDRiYmIyNDA+DQoNCg0KDQpK b2luIGJ5IHBob25lDQpUYXAgdG8gY2FsbCBpbiBmcm9tIGEgbW9iaWxlIGRldmljZSAoYXR0ZW5k ZWVzIG9ubHkpDQoxLTY1MC00NzktMzIwODx0ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCowMSo2NDEw NjY5OTIlMjMlMjMqMDEqPiBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpDQoNCg0KDQpK b2luIGZyb20gYSB2aWRlbyBzeXN0ZW0gb3IgYXBwbGljYXRpb24NCkRpYWwgNjQxMDY2OTkyQGll dGYud2ViZXguY29tDQpZb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVudGVyIHlv dXIgbWVldGluZyBudW1iZXIuDQoNCg0KDQpKb2luIHVzaW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1p Y3Jvc29mdCBTa3lwZSBmb3IgQnVzaW5lc3MNCkRpYWwgNjQxMDY2OTkyLmlldGZAbHluYy53ZWJl eC5jb20NCg0KTmVlZCBoZWxwPyBHbyB0byBodHRwOi8vaGVscC53ZWJleC5jb20NCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkFjZSBtYWlsaW5nIGxp c3QNCkFjZUBpZXRmLm9yZzxtYWlsdG86QWNlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCg== --_000_4F6D9FFF82B541C1B6D6CD0EB8BD5F53ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0Ii IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+U29ycnksIHNlbnQgdG9vIGVhcmx5Lg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5UaGUgZGV0YWlscyBhYm91dCB0aGUgdXBkYXRlIHdpbGwgYmUgY292ZXJl ZCBpbiB0aGUgc2xpZGVzIGZvciB0aGUgaW50ZXJpbSAoc29vbiB0byBiZSBzZW50IHRvIGNoYWly cyBmb3IgdXBsb2FkKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkxlZnQgdG8gZG86IGluY2x1ZGUgdGhlIHJldmll dyBjb21tZW50cyBsZWZ0IGZyb20gUGV0ZXIgYW5kIGRpc2N1c3MgYSBmZXcgb3BlbiBpc3N1ZXMs IHdoaWNoIGFyZSBhbnl3YXlzIHN0cmFpZ2h0Zm9yd2FyZCB0byBpbXBsZW1lbnQgb25jZSB0aGUg d2cgaGFzIGRlY2lkZWQuIE9uY2UgdGhlc2UgYXJlIGRvbmUsIHdoaWNoIHdlIHRoaW5rIGNvdWxk IHRha2UgYSBjb3VwbGUNCiBvZiBzdWJtaXNzaW9ucywgaWYgd2UgZG9u4oCZdCBnZXQgYW55IG5l Z2F0aXZlIGZlZWRiYWNrIHdlIGNvdWxkIGdvIGZvciBXR0xDLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj5UaGFua3MsPGJyPg0KRnJhbmNlc2NhPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkFjZSAmbHQ7 YWNlLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBGcmFuY2VzY2EgUGFsb21iaW5p ICZsdDtmcmFuY2VzY2EucGFsb21iaW5pPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnJmd0 Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIDI3IEphbnVhcnkgMjAyMCBhdCAxMDozODxicj4N CjxiPlRvOiA8L2I+RGFuaWVsIE1pZ2F1bHQgJmx0O2RhbmllbC5taWdhdWx0PTQwZXJpY3Nzb24u Y29tQGRtYXJjLmlldGYub3JnJmd0OywgJnF1b3Q7YWNlLWNoYWlyc0BpZXRmLm9yZyZxdW90OyAm bHQ7YWNlLWNoYWlyc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzogPC9iPkFjZSBXZyAmbHQ7YWNl QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW0FjZV0gV2ViZXggbWVldGlu ZyBpbnZpdGF0aW9uOiBBQ0UgaW50ZXJpbSBtZWV0aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+SGksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlOiBzdGF0dXMgdXBkYXRlIGFjZS1rZXktZ3JvdXBj b21tOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5UaGUgZG9jdW1lbnQgaGFzIGJlZW4gdXBkYXRlZCB0byB2LTA0IGluIHByZXBh cmF0aW9uIGZvciBuZXh0IHdlZWsgaW50ZXJpbS4gVGhlIHVwZGF0ZSBjb3ZlcnMgYWxtb3N0IGFs bCByZXZpZXcgY29tbWVudHMgcmVjZWl2ZWQsIGluY2x1ZGluZyB3aGF0IGRpc2N1c3NlZCBhdCBJ RVRGMTA2Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkFjZSAmbHQ7 YWNlLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBEYW5pZWwgTWlnYXVsdCAmbHQ7 ZGFuaWVsLm1pZ2F1bHQ9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+ RGF0ZTogPC9iPkZyaWRheSwgMjQgSmFudWFyeSAyMDIwIGF0IDEzOjM4PGJyPg0KPGI+VG86IDwv Yj4mcXVvdDthY2UtY2hhaXJzQGlldGYub3JnJnF1b3Q7ICZsdDthY2UtY2hhaXJzQGlldGYub3Jn Jmd0Ozxicj4NCjxiPkNjOiA8L2I+QWNlIFdnICZsdDthY2VAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+ U3ViamVjdDogPC9iPlJlOiBbQWNlXSBXZWJleCBtZWV0aW5nIGludml0YXRpb246IEFDRSBpbnRl cmltIG1lZXRpbmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkhpLCZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGlzIGlzIGEgcmVtaW5kZXIgb2YgdGhlIGludGVyaW0gbWVldGluZyBu ZXh0IHdlZWsuIEJ5IHRoZSBpbnRlcmltJm5ic3A7bWVldGluZywgd2Ugd291bGQmbmJzcDtlc3Bl Y2lhbGx5IGFwcHJlY2lhdGUgeW91ciBmZWVkIGJhY2tzIG9uIHRoZSBmb2xsb3dpbmcgZG9jdW1l bnRzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4qIGFjZS1tcXR0LXByb2ZpbGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiogYWNlLWtleS1ncm91cGNvbW08bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiogYWNlLWtleS1ncm91cGNvbW0t b3Njb3JlJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgd291bGQgYWxzbyBhc2sgdGhlIGF1dGhvcnMgdG8gcmVzcG9uZCB0byB0aGlz IGVtYWlsJm5ic3A7d2l0aCBhIChzaG9ydCkgc3RhdHVzIHVwZGF0ZSBmb3IgZWFjaCBXRyBkb2N1 bWVudHMuIEVzcGVjaWFsbHkgbWVudGlvbmluZyBob3cgZmFyIGVhY2ggZG9jdW1lbnQgaXMgLSBp biB0aGVpciBvcGluaW9uIC0gZnJvbSBhIFdHTEMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdXJzLCZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QUNFIGNoYWlyczxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bMV0mbmJz cDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWFj ZS1tcXR0LXRscy1wcm9maWxlLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1hY2UtbXF0dC10bHMtcHJvZmlsZS88L2E+Jm5ic3A7Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bMl0mbmJzcDs8YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWFjZS1rZXktZ3Jv dXBjb21tLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1hY2Ut a2V5LWdyb3VwY29tbS88L2E+Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bM10mbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWFjZS1rZXktZ3JvdXBjb21tLW9zY29yZS8i Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYWNlLWtleS1ncm91 cGNvbW0tb3Njb3JlLzwvYT4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEphbiAyLCAyMDIwIGF0IDExOjI0IFBNIEFD RSBXb3JraW5nIEdyb3VwICZsdDs8YSBocmVmPSJtYWlsdG86bWVzc2VuZ2VyQHdlYmV4LmNvbSI+ bWVzc2VuZ2VyQHdlYmV4LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjx0YWJs ZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGFsaWdu PSJsZWZ0IiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJTtiYWNrZ3JvdW5kOndoaXRl Ij4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjIxLjBwdCI+DQo8dGQgc3R5bGU9InBhZGRp bmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDoyMS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7 bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFn cmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxl OmV4YWN0bHkiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0 ZCBzdHlsZT0icGFkZGluZzowY20gMTUuMHB0IDBjbSAxNS4wcHQiPg0KPHRhYmxlIGNsYXNzPSJN c29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCI+DQo8dGJvZHk+DQo8dHIg c3R5bGU9ImhlaWdodDoxNi41cHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43 NXB0IC43NXB0O2hlaWdodDoxNi41cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Imxp bmUtaGVpZ2h0OjE2LjVwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3Bh Y2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0 aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1o ZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkFDRSBX b3JraW5nIEdyb3VwIGludml0ZXMgeW91IHRvIGpvaW4gdGhpcyBXZWJleCBtZWV0aW5nLg0KPC9z cGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1l bnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVu dC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFs OmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFs VGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJo ZWlnaHQ6MTUuMHB0Ij4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVw dDtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdo dDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVw dDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFy YWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1 bGU6ZXhhY3RseSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9k eT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWVsZW1lbnQ6ZnJh bWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3Vu ZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hv ci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjx0YWJsZSBjbGFz cz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIwIiBz dHlsZT0id2lkdGg6MGNtIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVw dCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1o ZWlnaHQ6MTYuNXB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToy LjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2Fs OnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdo dC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+TWVldGluZyBudW1i ZXIgKGFjY2VzcyBjb2RlKTogNjQxIDA2NiA5OTINCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv dGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28t ZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBo O21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhh Y3RseSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRp bmc9IjAiIHdpZHRoPSIwIiBzdHlsZT0id2lkdGg6MGNtIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBz dHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTYuNXB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVt ZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1l bnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRh bDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+TWVldGluZyBwYXNzd29yZDogYWtaYVltZmY8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNv LWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFw aDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4 YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRk aW5nPSIwIj4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBwdCI+DQo8dGQgc3R5bGU9 InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQ7aGVpZ2h0OjE1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1l O21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7 bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3It aG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KJm5ic3A7PG86cD48 L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFj ZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRp Y2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhl aWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9 IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8 dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE2LjVwdDttc28tZWxl bWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdy YXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1l bnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+RnJpZGF5LCBKYW51YXJ5IDMxLCAyMDIwDQo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGlu ZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bGluZS1oZWlnaHQ6MTYuNXB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhz cGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZl cnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNv LWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4xMTow MCBhbSZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDsoVVRDLTA1OjAwKSBFYXN0ZXJuIFRpbWUgKFVT ICZhbXA7IENhbmFkYSkmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7MSBociAzMCBtaW5zDQo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZy YW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5j aG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1 bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxl IiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0 OjE1LjBwdCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgMy4wcHQgLjc1cHQ7aGVp Z2h0OjE1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUu MHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNv LWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFw aDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4 YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9k eT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWVsZW1lbnQ6ZnJh bWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3Vu ZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hv ci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjx0YWJsZSBjbGFz cz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIwIiBz dHlsZT0id2lkdGg6MGNtO2JvcmRlci1yYWRpdXM6MjBweDttaW4td2lkdGg6MTYwcHgiPg0KPHRi b2R5Pg0KPHRyPg0KPHRkIHdpZHRoPSIwIiBzdHlsZT0id2lkdGg6LjNwdDtwYWRkaW5nOi43NXB0 IC43NXB0IC43NXB0IC43NXB0Ij4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRl cj0iMSIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMCIgc3R5bGU9Indp ZHRoOjBjbTtiYWNrZ3JvdW5kOiM0M0E5NDI7Ym9yZGVyOnNvbGlkICM0M0E5NDIgMS4wcHQiPg0K PHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJib3JkZXI6bm9uZTtwYWRkaW5nOjcuNXB0IDI3LjBw dCA3LjVwdCAyNy4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5 bGU9InRleHQtYWxpZ246Y2VudGVyO21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1l LWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9y LXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47 bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHBzOi8vaWV0 Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW04OGZmMzZjY2FiMzhiNWUwNjVlNzg2NWMwNGJi YjI0MCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2NvbG9y OndoaXRlO3RleHQtZGVjb3JhdGlvbjpub25lIj5Kb2luIG1lZXRpbmc8L3NwYW4+PC9hPjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3Rk Pg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVs ZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDtt c28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0 bHkiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5n PSIwIj4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjM2LjBwdCI+DQo8dGQgc3R5bGU9InBh ZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQ7aGVpZ2h0OjM2LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MzYuMHB0O21zby1lbGVtZW50OmZyYW1lO21z by1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNv LWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9y aXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KJm5ic3A7PG86cD48L286 cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToy LjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2Fs OnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdo dC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAi IGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVw dCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1o ZWlnaHQ6MTguMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToy LjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2Fs OnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdo dC1ydWxlOmV4YWN0bHkiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Kb2luIGJ5IHBo b25lPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0 eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxOC4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1l bnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVu dC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFs OmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk5 OTk5OSI+VGFwIHRvIGNhbGwgaW4gZnJvbSBhIG1vYmlsZSBkZXZpY2UgKGF0dGVuZGVlcyBvbmx5 KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJw YWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJsaW5lLWhlaWdodDoxOC4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJh bWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNo b3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVt bjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMi PjxhIGhyZWY9InRlbDolMkIxLTY1MC00NzktMzIwOCwsKjAxKjY0MTA2Njk5MiUyMyUyMyowMSoi IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwQUZGOTt0ZXh0LWRlY29yYXRp b246bm9uZSI+MS02NTAtNDc5LTMyMDg8L3NwYW4+PC9hPiZuYnNwO0NhbGwtaW4gdG9sbCBudW1i ZXIgKFVTL0NhbmFkYSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4N Cjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+PC90ZD4NCjwvdHI+ DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tZWxl bWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdy YXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1l bnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHRh YmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2Vs bHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MjEuMHB0Ij4NCjx0ZCBz dHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY207aGVpZ2h0OjIxLjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MjEuMHB0O21zby1lbGVtZW50OmZyYW1lO21z by1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNv LWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9y aXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KJm5ic3A7PG86cD48L286 cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToy LjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2Fs OnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdo dC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAi IGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVw dCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1o ZWlnaHQ6MTguMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToy LjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2Fs OnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdo dC1ydWxlOmV4YWN0bHkiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Kb2luIGZyb20g YSB2aWRlbyBzeXN0ZW0gb3IgYXBwbGljYXRpb248L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0K PC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQg Ljc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE4LjBwdDtt c28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVt ZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNv LWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5 Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+RGlhbCA2NDEwNjY5OTJAaWV0Zi53ZWJl eC5jb208L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHls ZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTguMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50 LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQt YW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpj b2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMz MzMzIj5Zb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVudGVyIHlvdXIgbWVldGlu ZyBudW1iZXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0K PC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tZWxlbWVudDpmcmFtZTtt c28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21z by1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhv cml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJN c29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCI+DQo8dGJvZHk+DQo8dHIg c3R5bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43 NXB0IC43NXB0O2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Imxp bmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3Bh Y2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0 aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1o ZWlnaHQtcnVsZTpleGFjdGx5Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+ DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tZWxl bWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdy YXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1l bnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHRh YmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2Vs bHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTguMHB0 O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVs ZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDtt c28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0 bHkiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Kb2luIHVzaW5nIE1pY3Jvc29mdCBM eW5jIG9yIE1pY3Jvc29mdCBTa3lwZSBmb3IgQnVzaW5lc3M8L3NwYW4+PC9iPjxvOnA+PC9vOnA+ PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxOC4wcHQ7bXNv LWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVu dC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1l bGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPkRpYWwgNjQxMDY2OTkyLmlldGZAbHluYy53 ZWJleC5jb208L3NwYW4+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8 L3RhYmxlPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFk ZGluZz0iMCIgYWxpZ249ImxlZnQiIHdpZHRoPSIxMDAlIiBzdHlsZT0id2lkdGg6MTAwLjAlIj4N Cjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjU0LjBwdCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6 Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQ7aGVpZ2h0OjU0LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIu MjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6 cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0 LXJ1bGU6ZXhhY3RseSI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRy IHN0eWxlPSJoZWlnaHQ6MTguMHB0Ij4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAu NzVwdCAuNzVwdDtoZWlnaHQ6MTguMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJs aW5lLWhlaWdodDoxOC4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNw YWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVy dGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28t aGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5OZWVkIGhl bHA/IEdvIHRvDQo8YSBocmVmPSJodHRwOi8vaGVscC53ZWJleC5jb20iIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iY29sb3I6IzA0OUZEOTt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cDov L2hlbHAud2ViZXguY29tPC9zcGFuPjwvYT4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+ DQo8L3RyPg0KPHRyIHN0eWxlPSJoZWlnaHQ6MzMuMHB0Ij4NCjx0ZCBzdHlsZT0icGFkZGluZzou NzVwdCAuNzVwdCAuNzVwdCAuNzVwdDtoZWlnaHQ6MzMuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4y NXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpw YXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQt cnVsZTpleGFjdGx5Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Ri b2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCkFjZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86QWNlQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+QWNlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNlIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2U8L2E+PG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4F6D9FFF82B541C1B6D6CD0EB8BD5F53ericssoncom_-- From nobody Mon Jan 27 04:02:07 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07F112022C; Mon, 27 Jan 2020 04:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.759 X-Spam-Level: X-Spam-Status: No, score=-1.759 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SBL=0.141, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qw66J015rOC3; Mon, 27 Jan 2020 04:02:01 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2068.outbound.protection.outlook.com [40.107.21.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A67812001E; Mon, 27 Jan 2020 04:02:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q6JG9WWR80Gzc1GW2GbXCeqWoo2STEcuSihT2jETMU2Geq/DZmUd/5xGMcYam1GWONhMifvaE+I92CzivrieyOCPEIx59scKE+tQOvxhvOaiGEXmLsrK/p7SHcSaHXH3dUDKbxLzKSFOS8T9s6zk729vJOthcud0HrnWMseVaSTicp5HtrHRqUYi4vVW5+RC8Naty0xVxXICyVsqzRI3y5yBI6IrWZ+kG19tZHpiPI1jTdlC4qUzyeOCtKELmH63kLZtBbQLjPvWVizgJvJfPXV0aAW+h6F9upP3QGTChePr7iSH3sy0ZePQgFF/oOu7Hr++2N+tOpLX8Zt7S9HVhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=llOKfJw92HHNbfEWceRM9NzMTSC9d4fc7T8FAx8FpJg=; b=gWln3xKe9CSVS+7Rt8AxyqXaQNdDv/+2DWT7MyVxQgb1WRgmQDSevCOu5P8C4/kBCVQkhfGbczEQZTkDNE1wfaC/X5Z86gyCp4QbO4rB64w/ioYrKKk1zAiQ4j+0cjUgV57WsDLiCq0eRcIoE5TVFHawTpqVIawaYyRXfIhgfymSLMk9GACLpPHcfRi1E3WsfWEa4c9N74BgsMyXwm7GLEPbktEXj3mlWmrzmj7cK0oohGYZhV6bpKlCZGDRR6kPzErxezNdElfWvC1S5hqyDchavNUvAnl93u0pOes7XjcHsJtNWz2abpVer3yrHLwnjfGW6ebZj25z6HJo9SkxsQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=llOKfJw92HHNbfEWceRM9NzMTSC9d4fc7T8FAx8FpJg=; b=fBXr75MMbiZQq/z51IgGZP7YkK4/WUR0/Fs7MJ/nYnk7RFQmdCYSblwW50ya4DrZlGcRwSqlvXcBF37UC38/KaINLXvLmNFN8FXWtsMzUdBKvG7+UlIs1JmL/O8XYq3bhU2Kn5PuCBiOdymkTALuxw/f3FxESqTJdoD5yZVqkYU= Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (10.165.195.159) by VI1P189MB0384.EURP189.PROD.OUTLOOK.COM (10.165.196.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.23; Mon, 27 Jan 2020 12:01:58 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::3485:ce83:891b:469]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::3485:ce83:891b:469%4]) with mapi id 15.20.2665.017; Mon, 27 Jan 2020 12:01:58 +0000 Received: from [10.8.8.48] (196.196.244.76) by HE1P191CA0001.EURP191.PROD.OUTLOOK.COM (2603:10a6:3:cf::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.20 via Frontend Transport; Mon, 27 Jan 2020 12:01:58 +0000 From: Marco Tiloca To: Daniel Migault , "ace-chairs@ietf.org" CC: Ace Wg Thread-Topic: [Ace] Webex meeting invitation: ACE interim meeting Thread-Index: AQHVwe2zavUC4Aca10GKgK1FfNVhaKf54kEAgAStAwA= Date: Mon, 27 Jan 2020 12:01:58 +0000 Message-ID: <2fac870e-60aa-4e21-6cc7-b2b51c135bb0@ri.se> References: <1871924156.4933601578025456778.JavaMail.nobody@rva2rmd101.webex.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-clientproxiedby: HE1P191CA0001.EURP191.PROD.OUTLOOK.COM (2603:10a6:3:cf::11) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) authentication-results: spf=none (sender IP is ) smtp.mailfrom=marco.tiloca@ri.se; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [196.196.244.76] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: be5935cf-f4ec-44b8-7864-08d7a320b5f4 x-ms-traffictypediagnostic: VI1P189MB0384: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1201; x-forefront-prvs: 02951C14DC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(346002)(396003)(376002)(136003)(39860400002)(199004)(189003)(66574012)(316002)(110136005)(16576012)(4326008)(31686004)(966005)(478600001)(2906002)(52116002)(45080400002)(66946007)(16799955002)(64756008)(53546011)(66446008)(81156014)(81166006)(36756003)(8676002)(66616009)(5660300002)(8936002)(6486002)(66556008)(66476007)(71200400001)(26005)(44832011)(956004)(2616005)(16526019)(31696002)(86362001)(5001810100001)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P189MB0384; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ri.se does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ydjaYFfvBAjR7j7J6dFZuA+DPRpr17Q9BlKT8SH6hhKGcixBI5OnUxUxJ8723y0eFJHWVHWVvoVQQidPMSemCW9DmuqsxKzNA29+SzWCLaRlc9z6lVhh164YvmlmAKRABSRyPAjAfqK5NmeopOsNUS1paWqZoEqUm+9k1/dJh9QXLLCzLleAvrsNjINkZxVjKHoVBpehLdlv9Rqik+dthzOpBGnVVUJtbk3Q1+Udq+p58Y3WirERINf99yekorqD2jIIsB5tN1yBkMbRlA5fuO9nrrbn6giuBrAA0JsqPWZSvuKL/boGmQYYtx02o6NKcHDxRWCgEIW2aD6R9EPOTzsYI/FpzfJ9nrdHbAdudS3wZZY/lxRZHX+NLOWRpyWSEBvmxBmiuUJWO3O71MrSzyFqTIToG75iFD2iBX58K5lXU7qT40yI1ZzuaxLm/WYYvCzeeb0PTx+jfZHz9+0zlKKvDKV3z+GBhvi40krk3+A= x-ms-exchange-antispam-messagedata: YvsorZtlfHCQnfdjx6XYQQXCAPAC+FztBPuAs6d38TOzA/LihT324+iHsrjLPaMhDCJ7d+XZfnNsY47WkIBNqC9qRCzGhA2Kesg7Ktmo4bGUoOSYPYV/2lYpdEjjaqAcBVrJnt8VFCAyklGtsU9vJg== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oAHFmI75318WKGW48rRREBfgYu0Ovb0Fk" MIME-Version: 1.0 X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: be5935cf-f4ec-44b8-7864-08d7a320b5f4 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2020 12:01:58.5751 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7YZuLXfVm4/qVrI6T610cKJK3ZbAM95Xi2Hkw6N2s+agopnup9NDyLufkfuLJ3sMFKQEMXjKi6TbcCZ0VB+NBw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0384 Archived-At: Subject: Re: [Ace] Webex meeting invitation: ACE interim meeting X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2020 12:02:05 -0000 --oAHFmI75318WKGW48rRREBfgYu0Ovb0Fk Content-Type: multipart/mixed; boundary="wCXvQHJXnEwsRwPQ4IjgB76EFzdsa3dF7" --wCXvQHJXnEwsRwPQ4IjgB76EFzdsa3dF7 Content-Type: multipart/alternative; boundary="------------C86BCCAD657E746FDB8C6DEA" Content-Language: en-US This is a multi-part message in MIME format. --------------C86BCCAD657E746FDB8C6DEA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Re: status of ace-key-groupcomm-oscore [ On the latest submitted -04 ] - General concepts/mechanisms were moved to ace-key-groupcomm . - Adapted API and messages format to the latest ace-key-groupcomm . - Building of signature challenges in different cases. - Editorial improvements, including Peter's review. - Compliance with new requirements for ACE groupcomm profiles. [ Expected timeline for WGLC ] - As very related to ace-key-groupcomm , it depends also on how that document advances and what changes it introduces. - We estimate 2 or 3 more updates (including one before the March cut-off), also based on lessons learnt from interop on the way. Best, /Marco On 2020-01-24 13:37, Daniel Migault wrote: > Hi,=C2=A0 > This is a reminder of the interim meeting next week. By the > interim=C2=A0meeting, we would=C2=A0especially appreciate your feed bac= ks on the > following documents.=C2=A0 > =C2=A0 > * ace-mqtt-profile > * ace-key-groupcomm > * ace-key-groupcomm-oscore=C2=A0 > > I would also ask the authors to respond to this email=C2=A0with a (shor= t) > status update for each WG documents. Especially mentioning how far > each document is - in their opinion - from a WGLC.=C2=A0 > =C2=A0 > Yours,=C2=A0 > ACE chairs > > [1]=C2=A0https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profi= le/=C2=A0=C2=A0 > [2]=C2=A0https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/= =C2=A0=C2=A0 > [3]=C2=A0https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm-= oscore/=C2=A0 > =C2=A0 > > On Thu, Jan 2, 2020 at 11:24 PM ACE Working Group > wrote: > > =C2=A0 > ACE Working Group invites you to join this Webex meeting. > > =C2=A0 > > Meeting number (access code): 641 066 992 > > Meeting password: akZaYmff > > =C2=A0 > > Friday, January 31, 2020 > 11:00 am=C2=A0=C2=A0|=C2=A0=C2=A0(UTC-05:00) Eastern Time (US & Can= ada)=C2=A0=C2=A0|=C2=A0=C2=A01 hr 30 mins > > =C2=A0 > > Join meeting > > > > =C2=A0 > > *Join by phone* > Tap to call in from a mobile device (attendees only) > 1-650-479-3208 > =C2=A0Call-in toll > number (US/Canada) > > =C2=A0 > > *Join from a video system or application* > Dial 641066992@ietf.webex.com > You can also dial 173.243.2.68 and enter your meeting number. > > =C2=A0 > > *Join using Microsoft Lync or Microsoft Skype for Business* > Dial 641066992.ietf@lync.webex.com > > =C2=A0 > Need help? Go to http://help.webex.com > =C2=A0 > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --------------C86BCCAD657E746FDB8C6DEA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi,

Re: status of ace-key-groupcomm-oscore

[ On the latest submitted -04 ]

- General concepts/mechanisms were moved to ace-key-groupcomm .
- Adapted API and messages format to the latest ace-key-groupcomm . - Building of signature challenges in different cases.
- Editorial improvements, including Peter's review.
- Compliance with new requirements for ACE groupcomm profiles.

[ Expected timeline for WGLC ]

- As very related to ace-key-groupcomm , it depends also on how that document advances and what changes it introduces.
- We estimate 2 or 3 more updates (including one before the March cut-off), also based on lessons learnt from interop on the way.

Best,
/Marco

On 2020-01-24 13:37, Daniel Migault wrote:
Hi,=C2=A0
This is a reminder of the interim meeting next week. By the interim=C2=A0meeting, we would=C2=A0especially appreciate your = feed backs on the following documents.=C2=A0
=C2=A0
* ace-mqtt-profile
* ace-key-groupcomm
* ace-key-groupcomm-oscore=C2=A0

I would also ask the authors to respond to thi= s email=C2=A0with a (short) status update for each WG documents= =2E Especially mentioning how far each document is - in their opinion - from a WGLC.=C2=A0
=C2=A0
Yours,=C2=A0
ACE chairs

=C2=A0

On Thu, Jan 2, 2020 at 11:2= 4 PM ACE Working Group <messenger@webex.com> wrote:
=
=C2=A0
=
ACE Working Group invites you to join this Webex meeting.
=C2=A0
=
Meeting number (access code): 641 066 992
Meeting password: akZaYmff
=C2=A0
Friday, January 31, 2020
11:00 am=C2=A0=C2=A0|=C2=A0=C2=A0(UTC-05:00) Eastern = Time (US & Canada)=C2=A0=C2=A0|=C2=A0=C2=A01 hr 30 mins
=C2=A0
Join meeting=
=C2=A0
Join by phone
Tap to call in from a mobile device (attendees only)
1-= 650-479-3208=C2=A0Call-in toll number (US/Canada)

=C2=A0
Join from a video system or application
Dial 641066992@ietf.webex= =2Ecom
You can also dial 173.243.2.68 and enter your meeting number.
=C2=A0
Join using Microsoft Lync or Microsoft Skype for Business
Dial 641066992.ietf@lync.= webex.com
=C2=A0
Need help? Go to ht= tp://help.webex.com
=C2=A0
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

____________________________=
___________________
Ace mailing list
Ace@ie=
tf.org
https://www.ietf.org/mailman/listinfo/ace


--=20
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistag=C3=A5ngen 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501
https://www=
=2Eri.se
--------------C86BCCAD657E746FDB8C6DEA-- --wCXvQHJXnEwsRwPQ4IjgB76EFzdsa3dF7-- --oAHFmI75318WKGW48rRREBfgYu0Ovb0Fk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl4u0TAACgkQ7iZktA5Y 2kN8TAgAiL7Un6hkzhUC39wxb4cyvbJlWtezKc05dkeKDQWoqBokc0s6WQk2iKTO 7H3CtISSuqAZR/Qcme8AH4yfxe+lhHZwHPOLx5Kz4KaZlBvdNZhVI3cWkd3vCHWj +P1mc92oYICucbLeRDDyz87UXAj9vUgJvhkrGax923u+Lk0sCUl89lbCEDuZ+GDd kv70t+JBbU37BowXj7DQx55Pze8yiovw/e333WQUFhUqoODpOenC6elayRM+47iw DHA4utESdO0lvFqaG8xVLCjVgOeGmNxBX3d0/nz8LQdWJivqaF7MhFls8wVhP6su /lbam+lXXYQZx+7lr+qhr4HqCJZxMA== =fyi2 -----END PGP SIGNATURE----- --oAHFmI75318WKGW48rRREBfgYu0Ovb0Fk-- From nobody Mon Jan 27 04:32:19 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77EBC120026; Mon, 27 Jan 2020 04:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clwyj7T36iKV; Mon, 27 Jan 2020 04:32:14 -0800 (PST) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 702AA120033; Mon, 27 Jan 2020 04:32:14 -0800 (PST) Received: by mail-vs1-xe34.google.com with SMTP id x18so5495084vsq.4; Mon, 27 Jan 2020 04:32:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GW2fXkqxwsXOreIxe8/CAKuiM8DGpE2oqn5tJG7mg+c=; b=uaNbjg6jAfPRZpGobg4THFfMoqwfXR+PZZpkDE12e35p1/s8xbRw1s5ksjsptdbMva TrYrCoKBlWDTNUMM4kJnl420fkYzXFaBbMewvrwkTXZym09TtBCieFojILpezAKqKcw6 nSY0d9JdZFB9Fwt5lqPhGFUU4YfsPyFQwQRVFSbu2J+d+N+QXIx1vjIYBdg42gaYJeL/ CGk8rF3DKuLQzTOzlo4Z1+ljvipHyaiMNBpSQ65FsfrD9z09ijNklA8Z3mkq2jRcZGwB FQBalOHASg4iS02vJIVI20nMPPnQk7yNDgRq32bHREFWeW9VzzFh2qeT4uTO9XoYYOZD owBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GW2fXkqxwsXOreIxe8/CAKuiM8DGpE2oqn5tJG7mg+c=; b=PjG0DWAIo+rteKorSovCkv1OLf+bQ3+HOkHMCaLRO+sICFuehGIoEkgfe08TSLmNbi l11DjwTUFC1kSc0Fo6dJj1xDmoXh4aCLrWQGa5T3F/VBoi1UxEAiHezJ+CmyDh+qkJNF 2NyPBPsvpN0s3ZGPuqPfF9Z+Ig09B4Sxa2l6UjVrOhotnGZmw3RGRiJsUQ/WgqsXXu5y 1J+YBTs2uyRf5jcK6tamEsMZKdcm5d8TwfDJDQn1F715AUjicBwWad+QMMcUIRUu2Gw4 Ixe4SLNaIfAv6C5wUrbpSS9HoWgJgj19QrlC376HKt0rg2cgNSPlIwp2p5/8wqeVIxbC gf0g== X-Gm-Message-State: APjAAAXo1mE4SQv+/Kt9JACZ3OHqfrrQqBPJf9eqUwwTBZfc21yxj2JI Zorg5mbih+w+eztCo+WhrrwkQkY60I7aX2UDSsCZPBCm X-Google-Smtp-Source: APXvYqwh9RTaSU8BDM9SqpDd26jSqGoetQHMM51t2beeCG0vlXkO3HnIb0uh6ZALQaFaJ8S9t4SJpnoj4kBvj2CRWm4= X-Received: by 2002:a05:6102:388:: with SMTP id m8mr2449891vsq.144.1580128333267; Mon, 27 Jan 2020 04:32:13 -0800 (PST) MIME-Version: 1.0 References: <1871924156.4933601578025456778.JavaMail.nobody@rva2rmd101.webex.com> In-Reply-To: From: Cigdem Sengul Date: Mon, 27 Jan 2020 12:32:02 +0000 Message-ID: To: Daniel Migault Cc: ace-chairs@ietf.org, Ace Wg Content-Type: multipart/alternative; boundary="0000000000000107f5059d1e4cb7" Archived-At: Subject: Re: [Ace] Webex meeting invitation: ACE interim meeting X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2020 12:32:18 -0000 --0000000000000107f5059d1e4cb7 Content-Type: text/plain; charset="UTF-8" Hello, Regarding the ace-mqtt-profile: - We are currently at version 3, which reorganised sections and text to improve clarity. Version 3 introduced the following: o Added the option of Broker certificate thumbprint in the 'rs_cnf' sent to the Client. o Nonce from the TLS Exporter for PoP, added to the IANA requirements that the label should be registered. o Added a client nonce, when Challenge/Response Authentication is used between Client and Broker. - Currently, working on Jim's comments, and Daniel's comments, which will be version 4. Also will clarify some text regarding wildcard permissions based on the thread with Jim. Expected timeline for WGLC: Expect 1-2 revisions On Fri, Jan 24, 2020 at 12:37 PM Daniel Migault wrote: > Hi, > This is a reminder of the interim meeting next week. By the > interim meeting, we would especially appreciate your feed backs on the > following documents. > > * ace-mqtt-profile > * ace-key-groupcomm > * ace-key-groupcomm-oscore > > I would also ask the authors to respond to this email with a (short) > status update for each WG documents. Especially mentioning how far each > document is - in their opinion - from a WGLC. > > Yours, > ACE chairs > > [1] https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/ > [2] https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/ > [3] https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm-oscore/ > > > On Thu, Jan 2, 2020 at 11:24 PM ACE Working Group > wrote: > >> >> ACE Working Group invites you to join this Webex meeting. >> >> Meeting number (access code): 641 066 992 >> Meeting password: akZaYmff >> >> Friday, January 31, 2020 >> 11:00 am | (UTC-05:00) Eastern Time (US & Canada) | 1 hr 30 mins >> >> Join meeting >> >> >> *Join by phone* >> Tap to call in from a mobile device (attendees only) >> 1-650-479-3208 <%2B1-650-479-3208,,*01*641066992%23%23*01*> Call-in toll >> number (US/Canada) >> >> *Join from a video system or application* >> Dial 641066992@ietf.webex.com >> You can also dial 173.243.2.68 and enter your meeting number. >> >> *Join using Microsoft Lync or Microsoft Skype for Business* >> Dial 641066992.ietf@lync.webex.com >> >> Need help? Go to http://help.webex.com >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >> > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --0000000000000107f5059d1e4cb7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

Regarding the ace-mqtt-profile:<= /div>
- We are currently at version 3, which reorganised sections and t= ext to improve clarity.=C2=A0
=C2=A0 Version 3 introduced the fol= lowing:
   o =
 Added the option of Broker certificate thumbprint in the 'rs_cnf'
      sent to the Client.

   o  Nonce from the TLS Exporter for PoP,
      added to the IANA requirements that the label should be
      registered.

   o  Added a client nonce, when Challenge/Response Authentication is
      used between Client and Broker.=20

- Currently, =
working on Jim's comments, and Daniel's comments, which will be ver=
sion 4. 
Also will=
 clarify some text regarding wildcard permissions based on the thread with =
Jim.

Expected timeline for WGL= C:
Expect 1-2 revi=
sions

On Fri, Jan 24, 2020 at 12:37 PM Daniel Migault <daniel= .migault=3D40ericsson.com@= dmarc.ietf.org> wrote:
Hi,=C2=A0
This is a reminder of the inte= rim meeting next week. By the interim=C2=A0meeting, we would=C2=A0especiall= y appreciate your feed backs on the following documents.=C2=A0
= =C2=A0
* ace-mqtt-profile
* ace-key-groupcomm<= /div>
* ace-key-groupcomm-oscore=C2=A0

I would also ask the authors to respond to this email=C2= =A0with a (short) status update for each WG documents. Especially mentionin= g how far each document is - in their opinion - from a WGLC.=C2=A0
=C2=A0
Yours,=C2=A0
ACE ch= airs


On Thu, Jan 2, 2020 at 11:24 PM ACE Working Group <<= a href=3D"mailto:messenger@webex.com" target=3D"_blank">messenger@webex.com= > wrote:
=C2=A0
=09
ACE Working Group invites you to join this Webex meeting.
=C2= =A0
Meeting number (access code): 641 066 992
Meeting password: akZaYmff
=20
=C2= =A0
Friday, January 31, 2020
11:00 am=C2=A0=C2=A0|=C2=A0=C2=A0(UTC-05= :00) Eastern Time (US & Canada)=C2=A0=C2=A0|=C2=A0=C2=A01 hr 30 mins
=20
=C2=A0
Join meeting
= =C2=A0
=
Join by phone
Tap to call in from a mobile device (attendees only)
1-650-479-32= 08=C2=A0Call-in toll number (US/Can= ada)
=C2=A0
=
Join from a video system or ap= plication
Dial 641066992@ietf.webex.com
You can also dial 173.243.2.68 and e= nter your meeting number.
=C2=A0
= =
Join using Microsoft Lync or Microsoft Skype for Business
Dial 641066992.ietf@lync.webex.com
=C2=A0
Need help? Go to http:/= /help.webex.com
=C2=A0
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--0000000000000107f5059d1e4cb7-- From nobody Wed Jan 29 04:10:14 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E98D1201DE; Wed, 29 Jan 2020 04:10:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-I0CnHQNsbi; Wed, 29 Jan 2020 04:10:07 -0800 (PST) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2FED1200F5; Wed, 29 Jan 2020 04:10:06 -0800 (PST) Received: by mail-vs1-xe32.google.com with SMTP id p14so2974351vsq.6; Wed, 29 Jan 2020 04:10:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5pw4y0L8m7DcAT/Ropmj/4p/HP/UjiAzkw6+fkHb4pU=; b=YMWmNo0xakARhHHIrcInnfWhV60LIk5ctbSXWfMXj2csCkVDt1jkvlNMo2NqMp48HO X25Sm0CwpBXpdgBGtzoIPDbR/y5GhjklkIcFzS6MFX9YuOTLXZ5lhCGB2qS0CU4D2FvT nsYQIiI/Y1cLhoi/JwNuTHl5X7WwOp2DiOj1clnjMZAvxhMpzeBDXnO+JVVa/egQwSR0 ypoGKbQTGJ1QLki0QWbiYKdK0HRqGFamn8a4iQfiyXGcG6BQXPvI03CCnLJ55h+4KVwr TXNsQJRgDGEMi1kU1SGjvQo0E0es8URgkcGLcGSGxVE1AOLuJLuS9u/0ldaJuJr1gjKs Gf8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5pw4y0L8m7DcAT/Ropmj/4p/HP/UjiAzkw6+fkHb4pU=; b=CBSCj2LDaQqmYl3Feyd9NLZg0ogi7rC5GFEmDKICpFA2GttP7PdLKO1x8jETyaTdUp ka/PgyS8+Xe55VqYUntM1kbuD/YQtAbpVK/7MLN9IX5IR2wAzeZ5Uf247ngKVXPWqHth ZjU55mL3cxDvhHzyWROHZwUWin3Xx5quN+/q27aavl+0Y1EWrm7XzqNRT2PizI1JFxA5 uoB0iwXfJ8vlZUU4xiXOwT3KtRElBbi6n1rM+42WIXsT1/GiKyRDmQTFYTNSqpB0Rj4o Ri6TS/tsOkCKPQHFPH9k4oAlxxlB6sK/zicmNgq8ptAlv5gHTwv0hpusBC97fQ7Srnkf 38jw== X-Gm-Message-State: APjAAAUYiqbrfwuc6jzw1PZ0ug19EhiDu/0htQLvuHXTfvd439HyAVoT Zy+/+aY2a19sihL3S3CqvLP6gvtwQi9cxRme3I4= X-Google-Smtp-Source: APXvYqyQBRlE695xjFqIMwUxR51qbwE10kTfrvsgs4Oe+ju7DQmLEar+K4qoWAnIESb8qL3lWhUq1OpxiEOOMSenYkE= X-Received: by 2002:a67:c798:: with SMTP id t24mr16437827vsk.62.1580299805568; Wed, 29 Jan 2020 04:10:05 -0800 (PST) MIME-Version: 1.0 References: <007401d5c0f3$6e80d320$4b827960$@augustcellars.com> <012301d5cda8$a5c74f00$f155ed00$@augustcellars.com> In-Reply-To: From: Cigdem Sengul Date: Wed, 29 Jan 2020 12:09:54 +0000 Message-ID: To: Daniel Migault Cc: Jim Schaad , Ace Wg , draft-ietf-ace-mqtt-tls-profile@ietf.org Content-Type: multipart/alternative; boundary="0000000000008cb2e4059d4638a4" Archived-At: Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-03 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 12:10:12 -0000 --0000000000008cb2e4059d4638a4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you for your review Daniel. Comments inside. On Tue, Jan 21, 2020 at 6:23 PM Daniel Migault wrote: > > In this document, topics, more specifically, Topic Names, are treated > as resources. The Clients are assumed to have identified the > publish/subscribe topics of interest out-of-band (topic discovery is > not a feature of the MQTT protocol). A resource owner can pre- > configure policies at the AS that give Clients publish or subscribe > permissions to different topics. > > AS should be expanded. As we introduce the ACE terminology, it > might be > good to specify if "resource" terminology is used related to RS. I am not > entirely sure... but if that is the case, it might be good to specify tha= t > these resources are hosted on a Resource Server. > > Though this is a very minor issue, there are multiple double spaces. > [CS] AS - Fixed. For RS related comment, added to the previous paragraph: "The MQTT Broker, which acts as the Resource Server (RS), is responsible distributing the messages published by the publishers to their subscribers. Blank spaces: Noted, will take care of them in the next version. > Clients use an access token, bound to a proof-of-possession (PoP) key = to > authorize with the MQTT Broker their connection and publish/ subscribe > permissions to topics. > > Though I am an not english native, I have difficulties to parse "to > authorize with the MQTT Broker..." This is what I understand from the > draft: > The permission to publish/suscbribe topics on a given MQTT Broker are > defined > by an access token, bound to a proof-of-possession (PoP) key. The token = is > provided by the AS and used by the Client's to access the RS. > [CS] OK. Changed to "Clients prove their permission to publish/subscribe to topics hosted on an MQTT broker using an access token, bound to a proof-of-possession (PoP) key." Is this more clear. > > In the context of this ACE profile, the Broker acts as > the Resource Server (RS). In the rest of the document the terms "RS" and > "Broker" are used interchangeably. This document describes how to > authorise > the following exchanges between the Clients and the Broker. > > How to authorize... The wording sounds to me a bit strange though I > would > not pretend to have a better wording either, wouldn't associated permissi= on > more in line with the ACE framework ? > [CS] Fixed authorize. Kept the rest the same.... > > o Connection requests from the Clients to the Broker > > o Publish requests from the Clients to the Broker, and from the > Broker to the Clients > > o Subscribe requests from Clients to the Broker > > This document does not protect the contents of the PUBLISH message > from the Broker, and hence, the content of the the PUBLISH message is > > the the > [CS] Fixed. > > > Sengul, et al. Expires June 22, 2020 [Page 3] > > Internet-Draft MQTT-TLS profile of ACE December 2019 > > > not signed or encrypted separately for the subscribers. This > > > It is the first time the document mentions PUBLISH. It would worth maybe = to > specify it is an MQTT message. > > I am wondering if encrypted stands for the opposite of not signed. If so,= a > document may be signed but not encrypted. I also understand that the > security > is performed by TLS or similar mechanism. If that is correct, it might be > clarifying to mention this is what we have in mind. It is also unclear > why we > introduce subscribers and not Clients. Are we excluding intentionally the > publishers? > > Maybe wording around: the PUBLISH message is unprotected or protected > via TLS (or equivalent mechanisms) for each Client's session. . > > What is unclear to me is what the "content" of the PUBLISH message > represents. > If that is the data associated to the topic. I would have expected > authentication being performed by a signature mechanism and the signature > being > generated by the content owner, that is (I expect) the publisher. I think > that > data protection is out-of scope as well as MQTT based mechanisms as MQTT > recommends TLS. > > > > [CS] Preceded the sentence with "Clients use MQTT PUBLISH message to publish to a topic." What I meant was protecting the payload from the Broker. At the moment, the broker is the end of TLS sessions for clients. So, the Broker does see all the payloads -> if we would like to introduce "confidential topics", which is the pub-sub document Francesca is working on, then the payload needs to be encrypted. Publishers do not sign the payload either. Not excluding publishers really, it is just that the subscribers are the recipients who would need to check the signature, decrypt if things were protected. Reworded as: "The document does not protect the payload of the PUBLISH message from the Broker, and hence, the payload is not signed or encrypted specifically for subscribers." > > functionality may be implemented using the proposal outlined in the > CoAP Pub-Sub Profile [I-D.palombini-ace-coap-pubsub-profile]. > > > To provide communication confidentiality and RS authentication, TLS > is used and TLS 1.3 is RECOMMENDED. This document makes the same > assumptions as the Section 4 of the ACE framework > [I-D.ietf-ace-oauth-authz] regarding Client and RS registration with > the AS and setting up keying material. > > Is registration appropriated for the RS to the AS? > [CS] I am not sure I understand the question. This was referring to " It is also assumed that the RS has been registered with the AS, potentially in a similar way as the client has been registered with the AS." in Section 4 of draft-ietf-ace-oauth-authz. > > > While the Client-Broker > exchanges are only over MQTT, the required Client-AS and RS-AS > interactions are described for HTTPS-based communication, using > 'application/ace+json' content type, and unless otherwise specified, > using JSON encoding. The token may be a reference, or JSON Web Token > (JWT). For JWT tokens, this document follows RFC 7800 [RFC7800] for > PoP semantics for JWTs. > > For my own understanding I would like to check if reference stands > for > reference to an access token or something else. > > [CS] This is what the draft-ietf-ace-oauth-authz says in Section 3.1, page 9: "The token is either a simple reference, or a structured information object." > The Client-AS and RS-AS may also be other > than HTTPS e.g., CoAP or MQTT. > > I suspect some words are missing. Maybe "may also use other transpo= rt > protocol to carry the JWT.<.mglt> > [CS] Corrected to: "The Client-AS and RS-AS MAY also use protocols other than HTTP e.g., CoAP or MQTT." > > 1.2. ACE-Related Terminology > > The terminology for entities in the architecture is defined in OAuth > 2.0 RFC 6749 [RFC6749] such as "Client" (C), "Resource Server" (RS) > and "Authorization Server" (AS). > > The term "Resource" is used to refer to an MQTT Topic Name, which is > defined in Section 1.3. Hence, the "Resource Owner" is any entity > that can authoritatively speak for the topic. > > The introduction is using "resource", I propose the introduction > text is > coherent with the Terminology used latter in the document. > [CS] Changed to "resource". > > 1.3. MQTT-Related Terminology > > The document describes message exchanges as MQTT protocol > interactions. The Clients are MQTT Clients, which connect to the > Broker to publish and subscribe to Application Messages, labeled with > their topics. For additional information, please refer to the MQTT > v5.0 - the OASIS Standard [MQTT-OASIS-Standard-v5] or the MQTT v3.1.1 > - the OASIS Standard [MQTT-OASIS-Standard]. > > MQTTS > Secured transport profile of MQTT. MQTTS runs over TLS. > > I am wondering how appropriated it is to have sentence without > verb. I > probably think it is safer to use verb. > [CS] In other IETF drafts, I typically see a definition without a verb. e..g, QUIC: The transport protocol described by this document. > > Broker > The Server in MQTT. It acts as an intermediary between the > Clients that publishes Application Messages, and the Clients > that made Subscriptions. The Broker acts as the Resource > Server for the Clients. > > Similar comment as before, there seems to have a missing verb. Whi= le > Broker is defined, Client is not defined as a special term but instead in > the > introduction of the section. I am wondering if that would not be cleaner = to > have Client also be defined. I am also wondering if Clients cannot be > designated as subscriber/publisher. Note this is a question I am > wondering, and > I do not think a specific terminology would be needed. Instead, I would > simply > suggest, that Clients includes subscribers and publishers as these terms > are > used later. > [CS] Checking some RFCs, I see it is very common to use sentences like below. Have the rules of how to write terminology changed? Added: Client: A device or program that uses MQTT. (similar to MQTT descriptions). It's actually important not to designate clients as publisher/subscriber. A client should be able to get permissions to subscribe to x, and publish to y. Assume a client has the role of sending out a summary of all published messages. It should be able to both publish and subscribe. > > Subscription > A subscription comprises a Topic Filter and a maximum Quality > of Service (QoS). > > It might be relevant to specify that subscriptions are associated t= o > one > session. > > [CS} Sure. Added "A subscription is associated with a single session" at the end. > Topic Filter > An expression that indicates interest in one or more Topic > Names. Topic Filters may include wildcards. > > MQTT sends various control messages across a network connection. The > following is not an exhaustive list and the control packets that are > not relevant for authorization are not explained. These include, for > instance, the PUBREL and PUBCOMP packets used in the 4-step handshake > required for the QoS level 2. > > As a general comment, I would recommend to have the same definition > as > those provided by MQTTv5. We could clearly mention these are from MQTTv5 > and > are repeated here for the document to self contained. There is probably a > balance to find to introduce terms that are not used in this document, so > some > definitions may be partial using [....]. This is mostly a suggestion. > > [CS] We actually mostly do that anyway. They are just more concise. > CONNECT > > > > > Sengul, et al. Expires June 22, 2020 [Page 5] > > Internet-Draft MQTT-TLS profile of ACE December 2019 > > > Client request to connect to the Broker. After a network > connection is established, this is the first packet sent by a > Client. > > I understand that network connection means the layers below MQTT. I > thing > this is confusing and would suggest to maybe remove "After a network > connection > is established," > [CS] OK. But, if we are following the advice of sticking with MQTT spec for definitions, here is what the original says: "After a Network Connection is established by a Client to a Server, the first packet sent from the Client to the Server MUST be a CONNECT packet". > > > SUBSCRIBE > The Client subscribe request. > > I would suggest to have similar wording for PUBLISH as for > SUBSCRIBE. > [CS] Changed to: "Subscribe request sent from a Client". > > 2. Authorizing Connection Requests > > This section specifies how Client connections are authorized by the > MQTT Broker.Figure 1 shows the basic protocol flow during connection > set-up.The token request and response use the /token endpoint at the > > I suspect "/" should not be here and that url path is not > intended. > > [CS] Fixed. > [...] > > 2.2.1. Client-Server Authentication over TLS and MQTT > > The Client and the Broker MUST perform mutual authentication. > > If I am correct this is also correct for the C-AS. > [CS] Yes, added to the previous section. Actually: According to draft-ietf-ace-oauth-authz: It is also REQUIRED that the communicating endpoints perform mutual authentication. Should it be repeated in the profile as well? > The > Client MAY authenticate to the Broker over MQTT or TLS. > > My understanding of the sentence above is that the Client MAY > authenticate. Unless I am missing something, I would rather see MUST > instead. > [CS]OK. The previous sentence say the Client MUST authenticate. It may use either MQTT or TLS to authenticate. Still, I changed the sentence to: "Client MUST authenticate to the Broker either over MQTT or TLS". > For MQTT, > the options are "None" and "ace". For TLS, the options are "Anon" > for anonynous client, and "Known(RPK/PSK)" for Raw Public Keys (RPK) > and Pre-Shared Keys (PSK), respectively. Combined, the Client > authentication takes the following options: > > o "TLS:Anon-MQTT:None": This option is used only for the topics that > do not require authorization, including the "authz-info" topic. > Publishing to the "authz-info" topic is described in > Section 2.2.2. > > It is a bit unseal to describe unauthenticated channel as mutually > authenticated. > [CS] Himmm, not sure how to deal with this. This is the first step to the Mutual authentication. I can take this out describe separately. And then have only 3 options for mutual authentication. Any thoughts? > > o "TLS:Anon-MQTT:ace": The token is transported inside the CONNECT > message, > and MUST be validated using one of the methods described in Section 2.2.2= . > This option also supports a tokenless connection request for AS discovery= . > > o "TLS:Known(RPK/PSK)-MQTT:none": For the RPK, the token MUST have > been published to the "authz-info" topic. For the PSK, the token > MAY be, alternatively, provided in the "psk_identity". The TLS > session set-up is as described in DTLS profile for ACE > [I-D.ietf-ace-dtls-authorize]. > > Just to me sure I understand it properly. In this case the RPK or > PSK is > the one contained into the token. DTLS authenticate the TLS client via a > CertificateRequest. Other information related to the topic are performed > by the > MQTT. In order to perform perform the TLS authentication, the token with > the > existing key needs to be found. The Broker upon receiving a CONNECT needs > to > keep track of the used token. > [CS] We use TLS - give the DTLS profile as an example of the set-up for ACE. Yes: The token is validated, the client is authenticated, a secure TLS channel with them using the info in the token. The topic authorisation happens when the client tries to publish or subscribe. > > o "TLS:Known(RPK/PSK)-MQTT:ace": This option SHOULD NOT be chosen. > In any case, the token transported in the CONNECT overwrites any > permissions passed during the TLS authentication. > > My understanding is that the same access token would be used. > Collision > would occurs when different access token would be used. However, when > authentication is performed using DTLS, the Broker, as I would understand > it, > keeps track of the used token, which should avoid the overwriting > rules. > [CS] This statement was in case two different tokens were used, the last valid token overwrites the former. i.e., u can not add to your permissions - there is no union. > > It is RECOMMENDED that the Client follows TLS:Anon-MQTT:ace. > > The Broker MUST be authenticated during the TLS handshake. If the > Client authentication uses TLS:Known(RPK/PSK), then the Broker is > authenticated using the respective method. > > I understand that when the server is authenticated using RPK, the > server > needs to be authenticated using RPK, but it is unclear why standard WPKI > would > not work. I understand that for PSK the same method can be used, though. > > > [CS] The language around TLS may have gotten more constrained because I wanted to follow roughly what DTLS profile for ACE says... Though I do not have specific experience with WPKI. 2.2.2. authz-info: The Authorization Information Topic > > > The Broker stores and indexes all tokens received to this topic in > its key store similar to DTLS profile for ACE > [I-D.ietf-ace-dtls-authorize]. This profile follows the > recommendation of Section 5.8.1 of ACE framework > [I-D.ietf-ace-oauth-authz], and expects that RS stores only one token > per proof-of-possession key, and any other token linked to the same > key overwrites existing token at the RS. > > I think the intend is to avoid having multiple access token that > could > have the same PoP with different permissions. Keeping only the latest doe= s > not > guarantee the client and the broker are considering the same ticket, and > MAY > force client to perform a two step authentication at any time. In case of > rekey > or synchronization issues, this might generate more traffic than needed. = I > would think that keeping track of the access token used by DTLS is safer, > the > way described here is only one way of doing it. > [CS] This is coming from draft-ietf-ace-oauth-authz, Page 37: This specification RECOMMENDS that an RS stores only one token per proof-of-possession key, meaning that an additional token linked to the same key will overwrite any existing token at the RS. I would like to follow this recommendation in this profile as it greatly simplifies the implementation. And, during a long MQTT session, the client may push new tokens. The behaviour should be the new token overwrites the old one. > 2.2.4.1. Proof-of-Possession Using a Challenge from the TLS session > > For this option, the Authentication Data MUST contain the token and > the keyed message digest (MAC) or the Client signature. The secret > that is used for the proof-of-possession calculation, i.e., to > calculate the keyed message digest (MAC) or the Client signature, is > obtained using a TLS exporter ([RFC5705] for TLS 1.2 and for TLS 1.3, > Section 7.5 of [RFC8446]). > > Just to make sure I follow, the secret is signed or MACed without > being > sent. The secret is not used to derive the key used to the signature or > MAC. > Instead this key is in the access token. If I am correct, the use of MAC > or > signature is defined by the PoP symmetric or asymmetric. Correct ? I > believe > the text could be clearer. > Yes, correct. Added to the github issue to make this text clearer: https://github.com/ace-wg/mqtt-tls-profile/issues/41 > > 2.2.4.2. Proof-of-Possession via Broker-generated Challenge/Response > > For this option, the RS follows a Broker-generated challenge/response > protocol. The success case is illustrated in Figure 4. If the > Authentication Data only includes the token, the RS MUST respond with > an AUTH packet, with the Authenticate Reason Code set to '0x18 > (Continue Authentication)'. This packet includes the Authentication > Method, which MUST be set to 'ace' and Authentication Data. The > Authentication Data MUST NOT be empty and contains an 8-byte nonce as > a challenge for the Client. The Client responds to this with an AUTH > packet with a reason code '0x18 (Continue Authentication)'. > Similarly, the Client packet sets the Authentication Method to 'ace'. > The Authentication Data in the Client's response contains a client- > generated 8-byte nonce, and the signature or MAC computed over the RS > nonce concatenated with the client nonce. Next, the token is > validated as described in Section 2.2.5. > > > I do not see exporters being involved, and if that is correct there > is no > channel binding. As DTLS is mandatory, wouldn't it be possible to add the > exporter to the nonces. This may also be used to increases the randomness > of > the nonces > > [CS] I have to admit, I have gone back and forth about this. Some implementers have commented not to have TLS exporter support... > [...] > > 3.1. PUBLISH Messages from the Publisher Client to the Broker > > On receiving the PUBLISH message, the Broker MUST use the type of > message (i.e., PUBLISH) and the Topic name in the message header to > match against the scope string in the cached token or its > introspection result. Following the example above, a client sending > a PUBLISH message to 'a/topic3' would be allowed to publish, as the > scope includes the string 'publish_+/topic3'. > > If the Client is allowed to publish to the topic, the RS must publish > > While "must" may not be necessary, if used, it could be > normative. > [CS] I tried to keep MQTT musts as "must" and this profile's musts as MUST. Wouldn't that be acceptable? > > 3.2. PUBLISH Messages from the Broker to the Subscriber Clients > > To forward PUBLISH messages to the subscribing Clients, the Broker > identifies all the subscribers that have valid matching topic > subscriptions (i.e., the tokens are valid, and token scopes allow a > subscription to the particular topic). The Broker sends a PUBLISH > message with the Topic name to all the valid subscribers. > > RS MUST stop forwarding messages to the unauthorized subscribers. > > I do not think they should have started. I am wondering if > s/stop/NOT/ > would not be better. > [CS] Fixed. > > 4. Token Expiration and Reauthentication > > > To re-authenticate, the Client sends an AUTH packet with reason code > '0x19 (Re-authentication)'. The Client MUST set the Authentication > Method as 'ace' and transport the new token in the Authentication > Data. The Client and the RS go through the same steps for proof of > possession validation as described in Section 2.2. The Client SHOULD > use the same method used for the first connection request. > > I am wondering if there are good reasons for SHOULD. I would say th= at > using multiple authentication method with different level of trust SHOULD > be > avoided. > [CS] I am not sure any more if that sentence is necessary.... Thanks for your review again, --Cigdem > > On Fri, Jan 17, 2020 at 9:40 PM Jim Schaad wrote= : > >> >> >> >> >> *From:* Cigdem Sengul >> *Sent:* Tuesday, January 14, 2020 8:25 AM >> *To:* Jim Schaad >> *Cc:* draft-ietf-ace-mqtt-tls-profile@ietf.org; Ace Wg >> *Subject:* Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-03 >> >> >> >> Thank you for this review, Jim. >> >> Responses inline. >> >> >> >> On Wed, Jan 1, 2020 at 10:33 PM Jim Schaad >> wrote: >> >> >> >> >> 2.2.2 - I am unclear under what circumstances you could end put with a >> token >> which does not parse when processing a PUBLISH message. If the token >> cannot >> be parsed at connection time, that I can understand. However having >> parsed >> the token then it does not make sense that the token becomes not parsabl= e >> at >> the time of publishing. Am I missing something? >> >> >> >> [CS] There is a misunderstanding. The PUBLISH message refers to the >> actual PUBLISH message to the "authz-info" topic which contains the toke= n >> i.e., this may not parse to a token. (The PUBLISH message is not for oth= er >> messages that are permissioned in the token.) >> >> The client connects (without much security), publishes the token to the >> public "authz-info" topic, which only the broker can read. >> >> Then, disconnects, and tries to connect with ace security. >> >> >> >> Since MQTT v5 can return error messages in response to PUBLISH messages, >> here, this is used to signal to the publisher that there is something wr= ong >> with its token. >> >> >> >> Added: https://github.com/ace-wg/mqtt-tls-profile/issues/38 >> >> >> >> [JLS] Ok =E2=80=93 I see where I got mixed in in reading this. I think = this may >> just be a problem on my end and you might not be able to do this better. >> >> >> >> >> >> >> >> >> 2.2.4 - I am having a problem with trying to parse the content of the AU= TH >> property. I have no problems with 2.2.4.3 because this is a zero length >> sequence of bytes. However for 2.2.4.1 and 2.2.4.2 there is a token >> (possibly binary with no length prefix) followed by an optional binary >> cryptographic value. For introspection, I would need to figure out the >> length of the token before I could make a guess at the length of the >> cryptographic value. However given that there is no divider this does n= ot >> seem possible. This may also become a problem for the response from the >> client in the event that there is a change from an 8-byte nonce to a >> variable length one. >> >> >> >> [CS] Not specified a format, because I thought we discarded the idea o= f >> using the variable-length nonce based on the meeting in Singapore. >> >> What would you suggest - introduce a specific format to accommodate >> variable length? >> >> length_of_token+binary data for token+(the rest is cryptographic value)? >> >> https://github.com/ace-wg/mqtt-tls-profile/issues/40 >> >> >> >> [JLS] I put in a comment on the github issue about what I was looking >> for. Additionally, my only possible problem with the fixed size nonce = is >> that the IESG or Security Directorate down the line may decide that it i= s >> too small for some reason (16 bytes signed by a 521-bit (65+ byte key)). >> Some might consider it to be small for a SHA-256 MAC operation. Not the >> exact same situation here for TLS as it is not really a compact protocol= . >> But it may considered to be for the IoT variants being used. I don=E2= =80=99t know. >> >> >> >> >> >> Jim >> >> >> >> >> I am going to play with something else. I am sure I will find other >> issues >> at a different time. >> >> >> >> Thank you for your review. Much appreciated. >> >> --Cigdem >> >> >> >> >> Jim >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Nits: >> Section 2 Para 1 s/Broker.Figure 1/Broker. Figure 1/ >> Section 2 Para 1 s/setup.The/setup. The/ >> Section 2.2.2 Last Para s/when the AS/when the RS/ >> >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >> > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --0000000000008cb2e4059d4638a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for your = review Daniel.
Comments inside.

On Tue, Jan 21, 2020 at 6:23= PM Daniel Migault <daniel.migault=3D40ericsson.com@dmarc.ietf.org> wrote= :

=C2=A0 =C2=A0In this document, topics, more specifically, Topic= Names, are treated
=C2=A0 =C2=A0as resources.=C2=A0 The Clients are ass= umed to have identified the
=C2=A0 =C2=A0publish/subscribe topics of int= erest out-of-band (topic discovery is
=C2=A0 =C2=A0not a feature of the = MQTT protocol).=C2=A0 A resource owner can pre-
=C2=A0 =C2=A0configure p= olicies at the AS that give Clients publish or subscribe
=C2=A0 =C2=A0pe= rmissions to different topics.

<mglt> AS should be expanded. A= s we introduce the ACE terminology, it might be
good to specify if "= ;resource" terminology is used related to RS. I am not
entirely sur= e... but if that is the case, it might be good to specify that
these res= ources are hosted on a Resource Server.

Though this is a very minor= issue, there are multiple double spaces.</mglt>

[CS] AS - Fixed.
For RS related comme= nt, added to the previous paragraph: "The MQTT Broker, which acts as t= he Resource Server (RS), is responsible
distributing the messages= published by the publishers to their subscribers.=C2=A0
Blank sp= aces: Noted, will take care of them in the next version.=C2=A0
=
=C2=A0
=C2=A0 =C2=A0Clients use an access token, bound to a proof-o= f-possession (PoP) key to
authorize with the MQTT Broker their connectio= n and publish/ subscribe
permissions to topics.

<mglt>Thou= gh I am an not english native, I have difficulties to parse "to
aut= horize with the MQTT Broker..." This is what I understand from the dra= ft:
The permission to publish/suscbribe topics on a given MQTT Broker ar= e defined
by an =C2=A0access token, bound to a proof-of-possession (PoP)= key. The token is
provided by the AS and used by the Client's to ac= cess the RS. </mglt>

= [CS] OK. Changed to "Clients prove their permission to publish/subscri= be to topics hosted on an MQTT broker using an access token, bound to a pro= of-of-possession (PoP) key."
Is this more clear.=C2=A0
=
=C2=A0In the context of this ACE profile, the Broker acts as
the Resour= ce Server (RS).=C2=A0 In the rest of the document the terms "RS" = and
"Broker" are used interchangeably.=C2=A0 This document des= cribes how to authorise
the following exchanges between the Clients and = the Broker.

<mglt>How to authorize... The wording sounds to me= a bit strange though I would
not pretend to have a better wording eithe= r, wouldn't associated permission
more in line with the ACE framewor= k ?</mglt>

[CS] Fixed= authorize. Kept the rest the same....

=C2=A0
=C2=A0 =C2=A0o =C2=A0Connection requests from the Clients to the Broker
=C2=A0 =C2=A0o =C2=A0Publish requests from the Clients to the Broker,= and from the
=C2=A0 =C2=A0 =C2=A0 Broker to the Clients

=C2=A0 = =C2=A0o =C2=A0Subscribe requests from Clients to the Broker

=C2=A0 = =C2=A0This document does not protect the contents of the PUBLISH message=C2=A0 =C2=A0from the Broker, and hence, the content of the the PUBLISH me= ssage is

<mglt>the the</mglt>

[CS] Fixed.=C2=A0


Sengul, et al. =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires June 22, 2020 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 3]
=0C
Internet-Draft =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 MQTT-TLS profile of ACE =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 December 2019


=C2=A0 =C2=A0not signed or encrypted= separately for the subscribers.=C2=A0 This

<mglt>
It is t= he first time the document mentions PUBLISH. It would worth maybe to
spe= cify it is an MQTT message.

I am wondering if encrypted stands for = the opposite of not signed. If so, a
document may be signed but not encr= ypted.=C2=A0 I also understand that the security
is performed by TLS or = similar mechanism. If that is correct, it might be
clarifying to mention= this is what we have in mind.=C2=A0 It is also unclear why we
introduce= subscribers and not Clients. Are we excluding intentionally the
publish= ers?
=C2=A0
Maybe wording around: the PUBLISH message is unprotected = or protected
via TLS (or equivalent mechanisms) for each Client's se= ssion. . =C2=A0

What is unclear to me is what the "content"= ; of the PUBLISH message represents.
If that is the data associated to t= he topic. I would have expected
authentication being performed by a sign= ature mechanism and the signature being
generated by the content owner, = that is (I expect) the publisher. I think that
data protection is out-of= scope as well as MQTT based mechanisms as MQTT
recommends TLS.

= </mglt>

[CS] Preceded the senten= ce with "Clients use MQTT PUBLISH message to publish to a topic."=

What I meant was protecting the payload from the = Broker. At the moment, the broker is the end of TLS sessions for clients.= =C2=A0
So, the Broker does see all the payloads -> if we would= like to introduce "confidential topics", which is the pub-sub do= cument Francesca is working on,=C2=A0
then the payload needs to b= e encrypted.=C2=A0 Publishers do not sign the payload either.=C2=A0

Not excluding publishers really, it is just that the subs= cribers are the recipients who would need to check the signature, decrypt i= f things were protected.
Reworded as: "The document does not= protect the payload of the PUBLISH message from the Broker, and hence, the= payload is not signed or encrypted
specifically for subscribers.= "=C2=A0
=C2=A0
=C2=A0

=C2=A0 =C2=A0fun= ctionality may be implemented using the proposal outlined in the
=C2=A0 = =C2=A0CoAP Pub-Sub Profile [I-D.palombini-ace-coap-pubsub-profile].

=
=C2=A0 =C2=A0To provide communication confidentiality and RS authentica= tion, TLS
=C2=A0 =C2=A0is used and TLS 1.3 is RECOMMENDED.=C2=A0 This do= cument makes the same
=C2=A0 =C2=A0assumptions as the Section 4 of the A= CE framework
=C2=A0 =C2=A0[I-D.ietf-ace-oauth-authz] regarding Client an= d RS registration with
=C2=A0 =C2=A0the AS and setting up keying materia= l.

<mglt> Is registration appropriated for the RS to the AS? = </mglt>

[CS] I am not= sure I understand the question.=C2=A0
This was referring to &quo= t; It is also assumed that the RS has been registered with the AS,
=C2= =A0 =C2=A0potentially in a similar way as the client has been registered wi= th
=C2=A0 =C2=A0the AS." in Section 4 of=C2=A0draft-ietf-ace-oauth-= authz.=C2=A0

=C2=A0 =C2=A0While the Client-Broker
=C2=A0 =C2=A0exchanges= are only over MQTT, the required Client-AS and RS-AS
=C2=A0 =C2=A0inter= actions are described for HTTPS-based communication, using
=C2=A0 =C2=A0= 'application/ace+json' content type, and unless otherwise specified= ,
=C2=A0 =C2=A0using JSON encoding.=C2=A0 The token may be a reference, = or JSON Web Token
=C2=A0 =C2=A0(JWT).=C2=A0 For JWT tokens, this documen= t follows RFC 7800 [RFC7800] for
=C2=A0 =C2=A0PoP semantics for JWTs.
<mglt>For my own understanding I would like to check if referen= ce stands for
reference to an access token or something else. =C2=A0 <= ;/mglt>


[CS] This is= what the=C2=A0 draft-ietf-ace-oauth-authz=C2=A0 says in Section 3.1, page 9: "The tok= en is either a simple reference, or a structured
=C2=A0 =C2=A0 =C2=A0 = information object."

=C2=A0
=C2=A0The Client-AS = and RS-AS may also be other
=C2=A0 =C2=A0than HTTPS e.g., CoAP or MQTT. = =C2=A0

<mglt>I suspect some words are missing. Maybe "may= also use other transport
protocol to carry the JWT.<.mglt>

[CS] Corrected to: "The Clie= nt-AS and RS-AS=C2=A0 MAY also use protocols other than HTTP e.g., CoAP or = MQTT."=C2=A0

1.2.=C2=A0 ACE-Related Terminology

=C2=A0 = =C2=A0The terminology for entities in the architecture is defined in OAuth<= br>=C2=A0 =C2=A02.0 RFC 6749 [RFC6749] such as "Client" (C), &quo= t;Resource Server" (RS)
=C2=A0 =C2=A0and "Authorization Server= " (AS).

=C2=A0 =C2=A0The term "Resource" is used to r= efer to an MQTT Topic Name, which is
=C2=A0 =C2=A0defined in Section 1.3= .=C2=A0 Hence, the "Resource Owner" is any entity
=C2=A0 =C2= =A0that can authoritatively speak for the topic.

<mglt>The int= roduction is using "resource", I propose the introduction text is=
coherent with the Terminology used latter in the document. </mglt>= ;

[CS] Changed to "re= source".=C2=A0
=C2=A0

1.3.=C2=A0 MQTT-Related Terminol= ogy

=C2=A0 =C2=A0The document describes message exchanges as MQTT pr= otocol
=C2=A0 =C2=A0interactions.=C2=A0 The Clients are MQTT Clients, wh= ich connect to the
=C2=A0 =C2=A0Broker to publish and subscribe to Appli= cation Messages, labeled with
=C2=A0 =C2=A0their topics.=C2=A0 For addit= ional information, please refer to the MQTT
=C2=A0 =C2=A0v5.0 - the OASI= S Standard [MQTT-OASIS-Standard-v5] or the MQTT v3.1.1
=C2=A0 =C2=A0- th= e OASIS Standard [MQTT-OASIS-Standard].

=C2=A0 =C2=A0MQTTS
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Secured transport profile of MQTT.=C2=A0= MQTTS runs over TLS.

<mglt> I am wondering how appropriated i= t is to have sentence without verb. I
probably think it is safer to use = verb.</mglt>

[CS] In = other IETF drafts, I typically see a definition without a verb.
<= br>
e..g,=C2=A0
=C2=A0QUIC: =C2=A0The transport protoco= l described by this document.=C2=A0
=C2=A0

=C2=A0 =C2= =A0Broker
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The Server in MQTT.= =C2=A0 It acts as an intermediary between the
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Clients that publishes Application Messages, and the Clien= ts
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that made Subscriptions.=C2= =A0 The Broker acts as the Resource
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Server for the Clients.

<mglt>Similar comment as before,= there seems to have a missing verb.=C2=A0 While
Broker is defined, Clie= nt is not defined as a special term but instead in the
introduction of t= he section. I am wondering if that would not be cleaner to
have Client a= lso be defined. I am also wondering if Clients cannot be
designated as s= ubscriber/publisher. Note this is a question I am wondering, and
I do no= t think a specific terminology would be needed. Instead, I would simply
= suggest, that Clients includes subscribers and publishers as these terms ar= e
used later. =C2=A0</mglt>

<= /div>
[CS] Checking some RFCs, I see it is very common to use sentences= like below.=C2=A0
Have the rules of how to write terminology cha= nged?

Added:
Client: A device or program= that uses MQTT. (similar to MQTT descriptions).=C2=A0

=
It's actually important not to designate clients as publisher/subs= criber.=C2=A0
A client should be able to get permissions to subsc= ribe to x, and publish to y.
Assume a client has the role of send= ing out a summary of all published messages.
It should be able to= both publish and subscribe.=C2=A0

=C2=A0

= =C2=A0 =C2=A0Subscription
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A sub= scription comprises a Topic Filter and a maximum Quality
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0of Service (QoS).

<mglt>It might be= relevant to specify that subscriptions are associated to one
session. = =C2=A0</mglt>

[CS} Sure. Added &= quot;A subscription is associated with a single session" at the end.= =C2=A0

=C2=A0
=C2=A0 =C2=A0Topic Filter
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0An expression that indicates interest= in one or more Topic
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Names.=C2= =A0 Topic Filters may include wildcards.

=C2=A0 =C2=A0MQTT sends var= ious control messages across a network connection.=C2=A0 The
=C2=A0 =C2= =A0following is not an exhaustive list and the control packets that are
= =C2=A0 =C2=A0not relevant for authorization are not explained.=C2=A0 These = include, for
=C2=A0 =C2=A0instance, the PUBREL and PUBCOMP packets used = in the 4-step handshake
=C2=A0 =C2=A0required for the QoS level 2.
<mglt>As a general comment, I would recommend to have the same defi= nition as
those provided by MQTTv5. We could clearly mention these are f= rom MQTTv5 and
are repeated here for the document to self contained. The= re is probably a
balance to find to introduce terms that are not used in= this document, so some
definitions may be partial using [....]. This is= mostly a suggestion. </mglt>

=
[CS] We actually mostly do that anyway. They are just more concise.=C2= =A0=C2=A0
=C2=A0
=C2=A0 =C2=A0CONNECT




Sengul= , et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires June 22, 2020 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 5]
=0C
Int= ernet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MQTT-TLS profile of ACE =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 December 2019


=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Client request to connect to the Broker.=C2=A0 Afte= r a network
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0connection is estab= lished, this is the first packet sent by a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Client.

<mglt>I understand that network connectio= n means the layers below MQTT. I thing
this is confusing and would sugge= st to maybe remove "After a network connection
is established,"= ;</mglt>

[CS] OK. But= , if we are following the advice of sticking with MQTT spec for definitions= , here is what the original says:
"After a Network Connection is established by a Client to a Se= rver, the first packet sent from the Client to the Server MUST be a CONNECT= packet".=C2=A0


=C2=A0 =C2=A0SUBSCRIBE
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The Client subscribe request.

<mgl= t>I would suggest to have similar wording for PUBLISH as for
SUBSCRIB= E.</mglt>

[CS] Change= d to: "Subscribe request sent from a Client".=C2=A0
=C2= =A0

2.=C2=A0 Authorizing Connection Requests

=C2=A0 =C2=A0This= section specifies how Client connections are authorized by the
=C2=A0 = =C2=A0MQTT Broker.Figure 1 shows the basic protocol flow during connection<= br>=C2=A0 =C2=A0set-up.The token request and response use the /token endpoi= nt at the

<mglt> I suspect "/" should not be here an= d that url path is not
intended.</mglt>


[CS] Fixed.
=C2=A0
[...]

2.2.1= .=C2=A0 Client-Server Authentication over TLS and MQTT

=C2=A0 =C2=A0= The Client and the Broker MUST perform mutual authentication. =C2=A0
<mglt>If I am correct this is also correct for the C-AS.</mglt>= ;
[CS] Yes, added to the previous section.= =C2=A0
Actually: According to=C2=A0=20 draft-ietf-ace-oauth-authz: It is also REQUIRED that the
=C2=A0 =C2=A0= communicating endpoints perform mutual authentication.
Should it be rep= eated in the profile as well?=C2=A0



=C2= =A0The
=C2=A0 =C2=A0Client MAY authenticate to the Broker over MQTT or T= LS.

<mglt>My understanding of the sentence above is that the = Client MAY
authenticate. Unless I am missing something, I would rather s= ee MUST
instead.</mglt>

[CS]OK. The previous sentence say the Client MUST authenticate.
=
It may use either MQTT=C2=A0 or TLS to authenticate.
Still, = I changed the sentence to:
"Client MUST authenticate to the = Broker either over MQTT or TLS".=C2=A0
=C2=A0
=C2= =A0
=C2=A0 =C2=A0For MQTT,
=C2=A0 =C2=A0the options are "None&quo= t; and "ace".=C2=A0 For TLS, the options are "Anon"
= =C2=A0 =C2=A0for anonynous client, and "Known(RPK/PSK)" for Raw P= ublic Keys (RPK)
=C2=A0 =C2=A0and Pre-Shared Keys (PSK), respectively.= =C2=A0 Combined, the Client
=C2=A0 =C2=A0authentication takes the follow= ing options:

=C2=A0 =C2=A0o =C2=A0"TLS:Anon-MQTT:None": Th= is option is used only for the topics that
=C2=A0 =C2=A0 =C2=A0 do not r= equire authorization, including the "authz-info" topic.
=C2=A0= =C2=A0 =C2=A0 Publishing to the "authz-info" topic is described = in
=C2=A0 =C2=A0 =C2=A0 Section 2.2.2.

<mglt>It is a bit un= seal to describe unauthenticated channel as mutually
authenticated.</= mglt>

[CS] Himmm, not su= re how to deal with this. This is the first step to the Mutual authenticati= on.=C2=A0
I can take this out describe separately. And then have = only 3 options for mutual authentication.=C2=A0
Any thoughts?
=C2=A0
=C2=A0
=C2=A0 =C2=A0o =C2=A0"TLS:Anon-MQTT:ace&= quot;: The token is transported inside the CONNECT message,
and MUST be = validated using one of the methods described in Section 2.2.2.
This opti= on also supports a tokenless connection request for AS discovery.

= =C2=A0 =C2=A0o =C2=A0"TLS:Known(RPK/PSK)-MQTT:none": For the RPK,= the token MUST have
=C2=A0 =C2=A0 =C2=A0 been published to the "au= thz-info" topic.=C2=A0 For the PSK, the token
=C2=A0 =C2=A0 =C2=A0 = MAY be, alternatively, provided in the "psk_identity".=C2=A0 The = TLS
=C2=A0 =C2=A0 =C2=A0 session set-up is as described in DTLS profile = for ACE
=C2=A0 =C2=A0 =C2=A0 [I-D.ietf-ace-dtls-authorize].

<m= glt> Just to me sure I understand it properly. In this case the RPK or P= SK is
the one contained into the token. DTLS authenticate the TLS client= via a
CertificateRequest. Other information related to the topic are pe= rformed by the
MQTT. In order to perform perform the TLS authentication,= the token with the
existing key needs to be found. The Broker upon rece= iving a CONNECT needs to
keep track of the used token. =C2=A0</mglt&g= t;

[CS] We use TLS - give t= he DTLS profile as an example of the set-up for ACE.=C2=A0
Yes: T= he token is validated, the client is authenticated, a secure TLS channel wi= th them using the info in the token.=C2=A0
The topic authorisatio= n happens when the client tries to publish or subscribe.=C2=A0
= =C2=A0

=C2=A0 =C2=A0o =C2=A0"TLS:Known(RPK/PSK)-MQTT:ace": = This option SHOULD NOT be chosen.
=C2=A0 =C2=A0 =C2=A0 In any case, the = token transported in the CONNECT overwrites any
=C2=A0 =C2=A0 =C2=A0 per= missions passed during the TLS authentication.

<mglt>My unders= tanding is that the same access token would be used. Collision
would occ= urs when different access token would be used. However, when
authenticat= ion is performed using DTLS, the Broker, as I would understand it,
keeps= track of the used token, which should avoid the overwriting rules.</mgl= t>

[CS] This statement w= as in case two different tokens were used, the last valid token overwrites = the former.=C2=A0
i.e., u can not add to your permissions - there= is no union.=C2=A0
=C2=A0

=C2=A0 =C2=A0It is RECOMMEND= ED that the Client follows TLS:Anon-MQTT:ace.

=C2=A0 =C2=A0The Broke= r MUST be authenticated during the TLS handshake.=C2=A0 If the
=C2=A0 = =C2=A0Client authentication uses TLS:Known(RPK/PSK), then the Broker is
= =C2=A0 =C2=A0authenticated using the respective method.

<mglt>= I understand that when the server is authenticated using RPK, the serverneeds to be authenticated using RPK, but it is unclear why standard WPKI w= ould
not work. I understand that for PSK the same method can be used, th= ough.
</mglt>

[CS] The langua= ge around TLS may have gotten more constrained because I wanted to follow r= oughly=C2=A0
what DTLS profile for ACE says...=C2=A0
Th= ough I do not have specific experience with WPKI.=C2=A0
=C2=A0

2.2.2. =C2=A0authz-info: The Authorization Information Topic=


=C2=A0 =C2=A0The Broker stores and indexes all tokens received = to this topic in
=C2=A0 =C2=A0its key store similar to DTLS profile for = ACE
=C2=A0 =C2=A0[I-D.ietf-ace-dtls-authorize].=C2=A0 This profile follo= ws the
=C2=A0 =C2=A0recommendation of Section 5.8.1 of ACE framework
= =C2=A0 =C2=A0[I-D.ietf-ace-oauth-authz], and expects that RS stores only on= e token
=C2=A0 =C2=A0per proof-of-possession key, and any other token li= nked to the same
=C2=A0 =C2=A0key overwrites existing token at the RS.
<mglt>I think the intend is to avoid having multiple access tok= en that could
have the same PoP with different permissions. Keeping only= the latest does not
guarantee the client and the broker are considering= the same ticket, and MAY
force client to perform a two step authenticat= ion at any time. In case of rekey
or synchronization issues, this might = generate more traffic than needed. I
would think that keeping track of t= he access token used by DTLS is safer, the
way described here is only on= e way of doing it. </mglt>

[CS] This is coming from=C2=A0draft-ietf-ace-oauth-authz, Page 37:

This specification RECOMMENDS that an RS stores onl= y one token per
=C2=A0 =C2=A0proof-of-possession key, meaning that an = additional token linked to
=C2=A0 =C2=A0the same key will overwrite any = existing token at the RS.=C2=A0

<= div class=3D"gmail_quote">I would like to follow this recommendation in thi= s profile as it greatly simplifies the implementation.=C2=A0
And, during a long MQTT session, the client may=C2=A0 pus= h new tokens. The behaviour should be the new token overwrites the old one.= =C2=A0

2.2.4.1.=C2=A0 Proof-of-Possession Using a Challenge from the TLS session=

=C2=A0 =C2=A0For this option, the Authentication Data MUST contain = the token and
=C2=A0 =C2=A0the keyed message digest (MAC) or the Client = signature.=C2=A0 The secret
=C2=A0 =C2=A0that is used for the proof-of-p= ossession calculation, i.e., to
=C2=A0 =C2=A0calculate the keyed message= digest (MAC) or the Client signature, is
=C2=A0 =C2=A0obtained using a = TLS exporter ([RFC5705] for TLS 1.2 and for TLS 1.3,
=C2=A0 =C2=A0Sectio= n 7.5 of [RFC8446]).

<mglt>Just to make sure I follow, the se= cret is signed or MACed without being
sent. The secret is not used to de= rive the key used to the signature or MAC.
Instead this key is in the ac= cess token.=C2=A0 If I am correct, the use of MAC or
signature is define= d by the PoP symmetric or asymmetric. Correct ? I believe
the text could= be clearer. =C2=A0</mglt>

Yes, correct. Added to the github issue to make this text clearer:
=C2=A0

2.2.4.2.=C2=A0 Proof-of-Possession via= Broker-generated Challenge/Response

=C2=A0 =C2=A0For this option, t= he RS follows a Broker-generated challenge/response
=C2=A0 =C2=A0protoco= l.=C2=A0 The success case is illustrated in Figure 4.=C2=A0 If the
=C2= =A0 =C2=A0Authentication Data only includes the token, the RS MUST respond = with
=C2=A0 =C2=A0an AUTH packet, with the Authenticate Reason Code set = to '0x18
=C2=A0 =C2=A0(Continue Authentication)'.=C2=A0 This pac= ket includes the Authentication
=C2=A0 =C2=A0Method, which MUST be set t= o 'ace' and Authentication Data.=C2=A0 The
=C2=A0 =C2=A0Authenti= cation Data MUST NOT be empty and contains an 8-byte nonce as
=C2=A0 =C2= =A0a challenge for the Client.=C2=A0 The Client responds to this with an AU= TH
=C2=A0 =C2=A0packet with a reason code '0x18 (Continue Authentica= tion)'.
=C2=A0 =C2=A0Similarly, the Client packet sets the Authentic= ation Method to 'ace'.
=C2=A0 =C2=A0The Authentication Data in t= he Client's response contains a client-
=C2=A0 =C2=A0generated 8-byt= e nonce, and the signature or MAC computed over the RS
=C2=A0 =C2=A0nonc= e concatenated with the client nonce.=C2=A0 Next, the token is
=C2=A0 = =C2=A0validated as described in Section 2.2.5.


<mglt>I do = not see exporters being involved, and if that is correct there is no
cha= nnel binding. As DTLS is mandatory, wouldn't it be possible to add the<= br>exporter to the nonces. This may also be used to increases the randomnes= s of
the nonces</mglt>


[CS] I have to admit, I have gone back and forth about this.=C2=A0=
Some implementers have commented not to have=C2=A0 TLS exporter = support...=C2=A0


=C2=A0
[...]
=
3.1.=C2=A0 PUBLISH Messages from the Publisher Client to the Broker
=
=C2=A0 =C2=A0On receiving the PUBLISH message, the Broker MUST use the = type of
=C2=A0 =C2=A0message (i.e., PUBLISH) and the Topic name in the m= essage header to
=C2=A0 =C2=A0match against the scope string in the cach= ed token or its
=C2=A0 =C2=A0introspection result.=C2=A0 Following the e= xample above, a client sending
=C2=A0 =C2=A0a PUBLISH message to 'a/= topic3' would be allowed to publish, as the
=C2=A0 =C2=A0scope inclu= des the string 'publish_+/topic3'.

=C2=A0 =C2=A0If the Clien= t is allowed to publish to the topic, the RS must publish

<mglt&g= t;While "must" may not be necessary, if used, it could be normati= ve.</mglt>

[CS] I tri= ed to keep MQTT musts as "must" and=C2=A0 this profile's must= s as MUST.=C2=A0
Wouldn't that be acceptable?
=C2= =A0

3.2.=C2=A0 PUBLISH Messages from the Broker to the Subscriber Cli= ents

=C2=A0 =C2=A0To forward PUBLISH messages to the subscribing Cli= ents, the Broker
=C2=A0 =C2=A0identifies all the subscribers that have v= alid matching topic
=C2=A0 =C2=A0subscriptions (i.e., the tokens are val= id, and token scopes allow a
=C2=A0 =C2=A0subscription to the particular= topic).=C2=A0 The Broker sends a PUBLISH
=C2=A0 =C2=A0message with the = Topic name to all the valid subscribers.

=C2=A0 =C2=A0RS MUST stop f= orwarding messages to the unauthorized subscribers.

<mgtl>I do= not think they should have started. I am wondering if s/stop/NOT/
would= not be better.</mglt>

[CS] Fixed.
=C2=A0

4.=C2=A0 Token Expiration and Reauthen= tication


=C2=A0 =C2=A0To re-authenticate, the Client sends an AU= TH packet with reason code
=C2=A0 =C2=A0'0x19 (Re-authentication)= 9;.=C2=A0 The Client MUST set the Authentication
=C2=A0 =C2=A0Method as = 'ace' and transport the new token in the Authentication
=C2=A0 = =C2=A0Data.=C2=A0 The Client and the RS go through the same steps for proof= of
=C2=A0 =C2=A0possession validation as described in Section 2.2.=C2= =A0 The Client SHOULD
=C2=A0 =C2=A0use the same method used for the firs= t connection request.

<mglt>I am wondering if there are good = reasons for SHOULD. I would say that
using multiple authentication metho= d with different level of trust SHOULD be
avoided. </mglt>

[CS] I am not sure any more if tha= t sentence is necessary....

Thanks for your review= again,
--Cigdem=C2=A0



=

= On Fri, Jan 17, 2020 at 9:40 PM Jim Schaad <ietf@augustcellars.com> wrote:
<= div>

=C2=A0

<= u>=C2=A0

From: Cigdem Sengul &l= t;cigdem.sengu= l@gmail.com>
Sent: Tuesday, January 14, 2020 8:25 AM
<= b>To: Jim Schaad <ietf@augustcellars.com>
Cc: draft-ietf-ace-= mqtt-tls-profile@ietf.org; Ace Wg <ace@ietf.org>
Subject: Re: [Ace] Review o= f draft-ietf-ace-mqtt-tls-profile-03

=C2=A0

T= hank you for this review, Jim.=C2=A0

Responses inline.=C2=A0

=C2=A0

On= Wed, Jan 1, 2020 at 10:33 PM Jim Schaad <ietf@augustcellars.com> wrote:<= u>




2.2.2 - I am unclear under what circumstan= ces you could end put with a token
which does not parse when processing = a PUBLISH message.=C2=A0 If the token cannot
be parsed at connection tim= e, that I can understand.=C2=A0 However having parsed
the token then it = does not make sense that the token becomes not parsable at
the time of p= ublishing.=C2=A0 Am I missing something?

=C2=A0

[CS] There is a misunderstanding. The PUBLISH message refers to the = actual PUBLISH message to the "authz-info" topic which contains t= he token i.e., this may not parse to a token. (The PUBLISH message is not f= or other messages that are permissioned in the token.)

The client connects (without much security),= publishes the token to the public "authz-info" topic, which only= the broker can read.=C2=A0

Then, disconnects, and tries to connect with ace security.=C2=A0=

=C2=A0

=

Since MQTT v5 can return error messages in resp= onse to PUBLISH messages, here, this is used to signal to the publisher tha= t there is something wrong with its token.=C2=A0

=C2=A0

Added:=C2=A0https://github.com/ace-wg/mqtt-tls-profile/issu= es/38

=C2=A0

<= p class=3D"MsoNormal">[JLS] Ok =E2=80=93 I see where I got mixed in in read= ing this.=C2=A0 I think this may just be a problem on my end and you might = not be able to do this better.

=C2=A0

=C2= =A0

=C2=A0


2.2.4 - I am having a = problem with trying to parse the content of the AUTH
property.=C2=A0 I h= ave no problems with 2.2.4.3 because this is a zero length
sequence of b= ytes.=C2=A0 However for 2.2.4.1 and 2.2.4.2 there is a token
(possibly b= inary with no length prefix) followed by an optional binary
cryptographi= c value.=C2=A0 For introspection, I would need to figure out the
length = of the token before I could make a guess at the length of the
cryptograp= hic value.=C2=A0 However given that there is no divider this does not
se= em possible.=C2=A0 This may also become a problem for the response from the=
client in the event that there is a change from an 8-byte nonce to avariable length one.

=C2=A0

[CS] Not spe= cified a=C2=A0 format, because I=C2=A0 thought we discarded the idea of usi= ng the variable-length nonce based on the meeting in Singapore.=C2=A0

What would you suggest - intr= oduce a specific format to accommodate variable length?

length_of_token+binary data for token+(the = rest is cryptographic value)?


I am going to play with something else.=C2=A0 I am= sure I will find other issues
at a different time.

=C2=A0

Thank you for your review. Much appreciated.=C2=A0<= /u>

--Cigdem=C2=A0

=C2=A0


Jim






=







Nits:
Section 2 Para 1 s/Broker.Figure 1= /Broker.=C2=A0 Figure 1/
Section 2 Para 1=C2=A0 s/setup.The/setup.=C2=A0= The/
Section 2.2.2 Last Para s/when the AS/when the RS/


____= ___________________________________________
Ace mailing list
Ace@ietf.org
https://www.iet= f.org/mailman/listinfo/ace

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--0000000000008cb2e4059d4638a4-- From nobody Wed Jan 29 06:42:46 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE766120088; Wed, 29 Jan 2020 06:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdZR6SPvbLrc; Wed, 29 Jan 2020 06:42:39 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30064.outbound.protection.outlook.com [40.107.3.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 700F512009C; Wed, 29 Jan 2020 06:42:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZYgbNCCTDSSAebJvV31n8VlbtoOs9UbjqHyBxUoBjvC/P8BUonUQSZ0JrGDmhtkikbAJWUg+PPqg810rmH7BO6SiRRUtO7x53odEc22zArxM/VDkgyyGLaZk/bAoDDrxbuDn8WJT89rz9ZphmByESPun82itZHd22af3NBJUr8iUNLKGUXbqsLHpbQHclTIzZF6EuVnW1G5KL7srdpAGPHdnyD0jHC5Ne7sQn+AkLVyqeozsSoWkA5lUuAnmQFmLlnr1mkpyl9+j8J6onGPblUbTby3Xl0nJ8esGlvPN6pQoGYmQYb07Z2A32y3h9lWj9VcH1l+3KHVwV4s9qtgUdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RjRn7x/mh8JHt1N2udMrpIj5Hs2MpNVSseLN9ZCUnnE=; b=jnZMFcM49zdr/Xd9iOQyPAwMrOGy9lc7rbdoncSYEScOV3grFaqu+oUO/ZolhYOBUxSGNAJvBZgfn5QRKACh6ffTQrWKj6uXMclFXis425A0tSH3D0xRSAVko1TFx528sxCAag6V8I8urxPbShYtQPHqyG8aHOGG0i1VYFJThNkw/8oVJ3iWsukaIn7OQPZ++PCF7au81icfjW9HyHCE0FjDwZJMc6cdhyJwOnvuqDZVMeTmPOak9CVwfeIIimo+GZF0vCEG+V8VV+u1iNY4UvKGsl0/vpaRfQWKPhZnNwKU8puix4MItj8TLm7FeWcHQNy+BBz4Qn/yOtl7vbNZFA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RjRn7x/mh8JHt1N2udMrpIj5Hs2MpNVSseLN9ZCUnnE=; b=AExuS/z4kfgi4p+40drh1gXkHdCw0DZ1zzBfvU8D9s15/du1Ti7REeZjc1Xi2FP2qj354jSV594XzQjZiAqwPz66dDVsxU07tNeE1IZjpdW8A6Ubp2aVLVcontHMm21ikfCBADRqET+O4OctSVUnqILoVmfCsulQi14TLTlpybU= Received: from AM6PR07MB4053.eurprd07.prod.outlook.com (52.134.117.139) by AM6PR07MB5461.eurprd07.prod.outlook.com (20.178.89.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.18; Wed, 29 Jan 2020 14:42:35 +0000 Received: from AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::7537:e135:422d:c5a7]) by AM6PR07MB4053.eurprd07.prod.outlook.com ([fe80::7537:e135:422d:c5a7%5]) with mapi id 15.20.2686.025; Wed, 29 Jan 2020 14:42:35 +0000 From: Francesca Palombini To: Benjamin Kaduk , "draft-ietf-ace-oscore-profile@ietf.org" , Ace Wg Thread-Topic: [Ace] AD review of draft-ietf-ace-oscore-profile-08 Thread-Index: AQHVxXkvf17L6O/aSkulV21bFzeHXqgB6oAA Date: Wed, 29 Jan 2020 14:42:34 +0000 Message-ID: <4086FADE-7993-47F6-9292-FDD7FC5457B4@ericsson.com> References: <20200107163851.GV57294@kduck.mit.edu> In-Reply-To: <20200107163851.GV57294@kduck.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=francesca.palombini@ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fe6cc061-42db-4388-75c2-08d7a4c97acf x-ms-traffictypediagnostic: AM6PR07MB5461: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(376002)(136003)(366004)(39860400002)(199004)(189003)(36756003)(76116006)(6512007)(30864003)(316002)(966005)(478600001)(44832011)(33656002)(6506007)(110136005)(86362001)(66946007)(6486002)(66476007)(66574012)(64756008)(66446008)(66556008)(91956017)(186003)(2906002)(2616005)(8676002)(5660300002)(71200400001)(81166006)(81156014)(8936002)(26005)(71600200004)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB5461; H:AM6PR07MB4053.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JkLIE4YWRKVcK3TQpjplKaVDsMk2pvvPAHfgRy0YGPesEplgowGwQDHHSm2n43GJK8UUt0Y/6BCA0IcUVKGKDwacQC15XhK4g8R57J1XdaIIItdec80rX46ITQG+PNTD0oKuBa3KEfJcLKoHXzUW2+rJHY2v6pWKIG4y6JN5u8HUDBlvmU2K2EVHu1WFnzYd6SocD4sIPDGacfDVUPknGfiCLtYWfJ+cepkDB9NfcygPytfRCKbwc0Zs4Ujl5p/V4kV5ZumDzTDnjDxGDxrB03uELWPn8pVeu3bSW6AYFyH33GVlF+Um3nxR2ldvXfI+Lzd6RuHofpmS0pj4YQ4BT02furOcALRG1W1rIOWAj4WsUZzSn9z0ywPSUpj5iiW/6fEycyFejs5WqjIxolbvE7A7hSaxWZY1juGyi9sUCMFxYc1xAz82TuMNgUaxleGI9Gjnx3yUq8FCGcGClZ/0GsXa/xWNQ+jL4haufWI73BW6H5U4TjBclyTkdTGQgYgr7nvrK62q22qL9ec2TTEMo15IjWOGUbKK5jQfVL25BnE2iZI61bI48BVVhdr+UhCUtt0JsZS2dTgdDumLr1rLRQ== x-ms-exchange-antispam-messagedata: Efjq4xSXtbDs/D+Ns7MfbnHxllYk3DJr2kulCE0mgIspnsZ1RS4r6WDAdCkkBLG1yQHsB59NuoSYNy1VkUk+ZGDv9UEbrlYtWDcHUrCOzfOe/JzeQ8N+hLEVeOTB+PYyjDzQ/V5JJ3JbMlYTYPY0Zw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: fe6cc061-42db-4388-75c2-08d7a4c97acf X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2020 14:42:35.0213 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pkggPQyT3UKjCMCeMLfavBNRSoJwBSQggNn3kC4jC1i4mQIBATL1WS1eaE/WQrUeSm1OBuC8t0XGfLOqZe7w0MPz6WzQMEGXyzXQvq+ovqAbFhwooYKLFx1HDN6V8F25 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5461 Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-oscore-profile-08 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 14:42:45 -0000 SGkgQmVuLA0KDQpUaGFuayB5b3Ugc28gbXVjaCBmb3IgdGhpcyB2ZXJ5IHRob3JvdWdoIGFuZCBp bi1kZXB0aCByZXZpZXchIA0KDQpJIGhhdmUgc3RhcnRlZCBhIFBSIChodHRwczovL2dpdGh1Yi5j b20vYWNlLXdnL2FjZS1vc2NvcmUtcHJvZmlsZS9wdWxsLzI1ICkgd2hlcmUgSSBwbGFuIHRvIGlu Y2x1ZGUgYWxsIHRoZSByZXZpZXcgY29tbWVudHMuIEkgaGF2ZSBzdGFydGVkIHdpdGggdGhlIGVk aXRvcmlhbCBmaXhlcywgd2hpY2ggSSBoYXZlIGNvbGxlY3RlZCBpbiBvbmUgaXNzdWU6IGh0dHBz Oi8vZ2l0aHViLmNvbS9hY2Utd2cvYWNlLW9zY29yZS1wcm9maWxlL2lzc3Vlcy8yNCANCg0KVGhl IGRldGFpbHMgb2YgYW5zd2VycyBhbmQgYWRkaXRpb25hbCBxdWVzdGlvbnMgZm9yIGNsYXJpZmlj YXRpb24gYXJlIGlubGluZSwgSSBhbHNvIG5vdGVkIHdpdGggIk9LIiB0aGUgcG9pbnRzIHdoZXJl IEkgYWdyZWUgd2l0aCB5b3VyIHN1Z2dlc3Rpb24gYW5kIGRvbid0IHNlZSBhbnkgcHJvYmxlbSBp bXBsZW1lbnRpbmcgaW4gdGhlIFBSLiBJIHdpbGwga2VlcCB0aGUgbnVtYmVyaW5nIGNvbnNpc3Rl bnQgaW4gdGhlIG1haWwgdGhyZWFkIGFuZCBpbiB0aGUgZ2l0aHViIHRvIG1ha2Ugc3VyZSBldmVy eXRoaW5nIGlzIGNvdmVyZWQuDQoNCkFkZGl0aW9uYWxseSwgeW91IG1hZGUgYSBudW1iZXIgb2Yg cG9pbnRzIEknZCBsaWtlIHRvIGdldCB3ZyBvcGluaW9uIG9uOg0KDQoqIFRoZSBtZWNoYW5pc20g b2YgbGV0dGluZyB0aGUgUlMgcGljayB0aGUgaWRlbnRpZmllciBvZiB0aGUgY2xpZW50IGlzIG5v dCB3b3J0aCB0aGUgYWRkaXRpb25hbCBjb21wbGV4aXR5LiBTbyBJIHByb3Bvc2Ugd2UgcmV2ZXJ0 IHRoYXQsIGFuZCBnbyBiYWNrIHRvIEFTIE1VU1QgcGljayB0aGUgY2xpZW50SWQsIHRoZSBjbGll bnRJZCBNVVNUIGJlIGluY2x1ZGVkIGluIHRoZSB0b2tlbi4gVGhpcyB3aWxsIG9ubHkgYWRkIHNv bWUgY29uc2lkZXJhdGlvbnMgYWJvdXQgdGhlIHNjZW5hcmlvIGhhcyBzZXZlcmFsLUFTLXBlci1S UywgaW4gd2hpY2ggY2FzZSB0aGVzZSBBUyBuZWVkIHRvIGJlIHN5bmNocm9uaXplZCBvbiBjbGll bnRJZHMgdGhleSBnaXZlIG91dC4gKDYuLCAyMS4sIDYxLiwgNjUuKQ0KKiBSZWNvbW1lbmRhdGlv biBhYm91dCBsZW5ndGggb2Ygbm9uY2VzIE4xIGFuZCBOMiB0byB1c2UuIFRoZSB3ZyBhZ3JlZWQg b24gNjQgYml0cywgbm93IEJlbiBzdWdnZXN0cyB0byB1c2UgMTI4IGJpdHMgbm9uY2VzLiBSZW1p bmRlcjogdGhlc2Ugbm9uY2VzIGFyZSBhcHBlbmRlZCB0byB0aGUgaW5wdXQgc2FsdCB0byBjcmVh dGUgdGhlIE1hc3RlciBTYWx0LCB0byBydW4gdGhlIEhLREYgYW5kIGRlcml2ZSB0aGUga2V5cy4g QWxzbyBjb25zaWRlciB0aGF0IE9TQ09SRSBhcHBlbmRpeCBCMiBoYXMgYSBzaW1pbGFyIHNldHRp bmcgYW5kIGRvZXMgc29tZSBjb25zaWRlcmF0aW9ucyBhYm91dCB0aGF0LCBtZW50aW9uaW5nIHRo YXQgInR5cGljYWxseSBub25jZXMgb2YgYXQgbGVhc3QgOCBieXRlcyB3aWxsIGJlIHVzZWQiLg0K KiBEZWZpbmUgYW5kIHJlZ2lzdGVyIDIgbmV3IEFDRSBwYXJhbWV0ZXJzIHRvIHRyYW5zcG9ydCB0 aGUgbm9uY2VzIHVzZWQgaW4gdGhlIGV4Y2hhbmdlLCBpbnN0ZWFkIG9mIHVzaW5nICJjbm9uY2Ui LiAoc2VlIHBvaW50IDMuLCA1My4pDQoqIERlZmluZSB0aGUgbm9uY2VzIGFzIGJzdHIgc28gdGhh dCBsZW5ndGggdmFsdWUgaXMgZW5jb2RlZC4gKDcuKQ0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzg2MTMjcGFnZS03MiANCiogRWRpdG9yaWFsOiBwb2ludCA3NS4NCg0KVGhhbmtzIGFn YWluIQ0KRnJhbmNlc2NhDQoNCu+7v09uIDA3LzAxLzIwMjAsIDE3OjQwLCAiQWNlIG9uIGJlaGFs ZiBvZiBCZW5qYW1pbiBLYWR1ayIgPGFjZS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBr YWR1a0BtaXQuZWR1PiB3cm90ZToNCg0KICAgIEhpIGFsbCwNCiAgICANCiAgICBTb21lIGhpZ2gt bGV2ZWwgcG9pbnRzIGJlZm9yZSB0aGUgc2VjdGlvbi1ieS1zZWN0aW9uIGNvbW1lbnRhcnk6DQog ICAgDQoxLiAgICBJJ20gYSBsaXR0bGUgY29uZnVzZWQgYnkgdGhlIHJlZ2lzdHJ5IHdlIGFyZSBj cmVhdGluZyBpbiBTZWN0aW9uIDkuMi4NCiAgICBXaGlsZSBpdCdzIGNsZWFyIHRoYXQgd2UgbmVl ZCBzb21ldGhpbmcgdG8gc3BlY2lmeSB0aGUgQ0JPUiBtYXAga2V5DQogICAgbGFiZWxzIHRvIGVu Y29kZSB0aGUgc3RydWN0dXJlIGZvciB0cmFuc2l0LCBpdCdzIG5vdCBjbGVhciB0aGF0IHdlIG5l ZWQNCiAgICBlYXN5IGV4dGVuc2liaWxpdHkgdnMuICBhIGZpeGVkIHRhYmxlLiAgQSByZWdpc3Ry eSBpbXBsaWVzIGV4cGVjdGF0aW9ucw0KICAgIG9mIGZ1dHVyZSBhZGRpdGlvbnMsIGJ1dCBkcmFm dC1pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5IGRpZCBub3QgZmVlbCBhDQogICAgbmVlZCB0byBt YWtlIGEgcmVnaXN0cnkgZm9yIGZ1dHVyZSBleHRlbnNpb25zOyB3aGF0IGhhcyBjaGFuZ2VkIGlu IHRoZQ0KICAgIHBhc3QgZmV3IG1vbnRocyB0aGF0IG1ha2VzIGV4dGVuc2liaWxpdHkgbmVlZGVk IG5vdz8gIFdoeSBpcyB0aGlzDQogICAgZG9jdW1lbnQgdGhlIHJpZ2h0IHBsYWNlIHRvIGNyZWF0 ZSB0aGUgcmVnaXN0cnkgYXMgb3Bwb3NlZCB0byB0aGF0IG9uZT8NCiAgICANCkZQOiBXaHkgZXh0 ZW5zaWJpbGl0eSBub3c6IGFuIGV4YW1wbGUgaXMgdGhlIEdyb3VwIE9TQ09SRSBwcm9maWxlLCB3 aGljaCBleHRlbmRzIHRoaXMgcmVnaXN0cnkgd2l0aCBmaWVsZHMgdGhhdCB0aGUgT1NDT1JFIHBy b2ZpbGUgZG9lcyBub3QgbmVlZCwgcmVsYXRlZCB0byBjb3VudGVyc2lnbmF0dXJlcyAoc2VlIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFjZS1rZXktZ3JvdXBjb21tLW9z Y29yZS0wNCNwYWdlLTIyICkuIFRoZSBkaWZmZXJlbmNlIGJldHdlZW4gT1NDT1JFIChSRkM4NjEz KSBhbmQgdGhpcyBkb2MgaXMgdGhhdCBpbiBPU0NPUkUgdGhlIHNlY3VyaXR5IGNvbnRleHQgaXMg bmV2ZXIgc2VudCBvbiB0aGUgd2lyZSwgaXQgaXMgYXNzdW1lZCB0byBiZSBwcmUtZXN0YWJsaXNo ZWQsIHdoaWxlIGhlcmUgd2UgbmVlZGVkIHRvIGRlZmluZSBhIHN0cnVjdHVyZSB0byBzZW5kLiBZ ZXMsIHdlIGNvdWxkIGF2b2lkIGRlZmluaW5nIHRoZSByZWdpc3RyeSBhbmQgZGVmaW5lIGFsbCB0 aGUgZmllbGRzICh3ZSBjYW4gdGhpbmsgb2YgcmlnaHQgbm93KSwgaW5jbHVkaW5nIHRob3NlIGZv ciBhY2Uta2V5LWdyb3VwY29tbS1vc2NvcmUgYXMgYSBmaXhlZCB0YWJsZSwgYnV0IHdlIHRob3Vn aHQgdGhpcyB3b3VsZCBiZSBiZXR0ZXIsIGFsc28gY29uc2lkZXJpbmcgdGhhdCB0aGUgT1NDT1JF IHNlY3VyaXR5IGNvbnRleHQgY291bGQgZ2V0IGV4dGVuZGVkIGluIGEgZnV0dXJlIHZlcnNpb24g b2YgT1NDT1JFLg0KDQoyLiAgICBXZSBhcmUgaW4gc29tZSBzZW5zZSBkZWZpbmluZyBhIG5ldyBz dWJzdHJ1Y3R1cmUgd2l0aGluICJraWQiIHZhbHVlcyAoYQ0KICAgIENCT1ItZW5jb2RlZCBhcnJh eSBvZiBvbmUgb3IgdHdvIGVsZW1lbnRzKSBmb3IgdXNhZ2UgYnkgdGhpbmdzIHVzaW5nDQogICAg dGhpcyBwcm9maWxlLiAgVGhhdCdzIHByb2JhYmx5IG5vdCBwcm9ibGVtYXRpYywgYXMgdGhlICJr aWQiIGNhbiBiZSBhbg0KICAgIGFyYml0cmFyeSBic3RyIGFuZCBpdHMgaW50ZXJwcmV0YXRpb24g aXMgdXAgdG8gdGhlIHJlY2lwaWVudCAtLSBhbnkNCiAgICByZWNpcGllbnQgdGhhdCBpbXBsZW1l bnRzIHRoaXMgcHJvZmlsZSB3aWxsIGtub3cgdG8gaGFuZGxlIHRoZQ0KICAgIHN1YnN0cnVjdHVy ZSwgYnV0IGl0IGRvZXMgZmVlbCBhIGxpdHRsZSB1bnVzdWFsIGFuZCBwZXJoYXBzIHdvcnRoIGFu DQogICAgZWFybHkgbm90ZS4gIChJSVVDLCB3ZSBhbHNvIG5lZWQgdG8gYmUgY2FyZWZ1bCBhYm91 dCBhY3R1YWxseSBwcm92aWRpbmcNCiAgICB0aGUgYnN0ciBmcmFtaW5nIGluIG91ciBleGFtcGxl cy4pDQogICAgDQpGUDogT2ssIEkgd2lsbCBhZGQgYW4gZWFybHkgbm90ZSBhbmQgYWxzbyBtYWtl IHN1cmUgdGhlIGFycmF5IGlzIHdyYXBwZWQgaW4gYSBic3RyLiBEbyB5b3UgaGF2ZSBhbnkgb3Bp bmlvbiBvbiB3aGVyZSBiZXN0IHRvIGFkZCB0aGlzIG5vdGU/IEtpZCBhcHBlYXJzIGZpcnN0IGlu IDMuMSwgc2hvdWxkIHdlIGhhdmUgaXQgaW4gdGhlIGludHJvZHVjdG9yeSBzZWN0aW9uIDMuPyBP ciB3ZXJlIHlvdSB0aGlua2luZyBldmVuIGJlZm9yZT8NCg0KMy4gICAgSSdtIGNvbmNlcm5lZCBh Ym91dCB0aGUgdXNhZ2Ugb2YgImNub25jZSIgdG8gY2FycnkgYm90aCBOMSBhbmQgTjIsDQogICAg bmVpdGhlciBvZiB3aGljaCBjb3JyZXNwb25kIHRvIHRoZSAiY25vbmNlIiBiZWhhdmlvciBpbiB0 aGUgY29yZQ0KICAgIGZyYW1ld29yazsgSSB0aGluayB3ZSBzaG91bGQgcGljayBhIGRpZmZlcmVu dCBwYXJhbWV0ZXIgbmFtZSBmb3IgdGhlDQogICAgZGlmZmVyZW5nIHNlbWFudGljIHVzYWdlLiAg U3BlY2lmaWNhbGx5LCB0aGUgY29yZS1mcmFtZXdvcmsgImNub25jZSIgaXMNCiAgICBhIHRvb2wg dG8gZ2l2ZSBSU2VzIHNvbWUgbW9kaWN1bSBvZiByZXBsYXkgcHJvdGVjdGlvbiAtLSBpdCB2ZXJp Zmllcw0KICAgIHRoYXQgdGhlIGNsaWVudCdzIGF1dGhvcml6YXRpb24gaW4gdGhlIHRva2VuIGlz ICJmcmVzaCIsIHNpbmNlIHRoZSB0b2tlbg0KICAgIGluY2x1ZGVzIHRoZSByYW5kb20gbm9uY2Ug Z2VuZXJhdGVkIGJ5IHRoZSBSUyBhbmQgY29udmV5ZCB0byB0aGUgQVMgdmlhDQogICAgdGhlIGNs aWVudC4gIFRoaXMgZG9jdW1lbnQgdXNlcyBhIHBhcmFtZXRlciBuYW1lZCAiY25vbmNlIiBpbiB0 d28gd2F5czoNCiAgICAoMSkgdG8gY29udmV5IHRoZSBjbGllbnQtZ2VuZXJhdGVkIG5vbmNlIE4x IHRvIHRoZSBSUyBpbiB0aGUgYXV0aHotaW5mbw0KICAgIHJlcXVlc3Q7IHRoaXMgaXMgZ2l2aW5n IHRoZSBjbGllbnQgY29udHJpYnV0b3J5IGJlaGF2aW9yIHRvIHRoZQ0KICAgIGVwaGVtZXJhbCBy YW5kb21uZXNzIGlucHV0IHRvIHRoZSBTZWN1cml0eSBDb250ZXh0IGNvbXB1dGF0aW9uIGJ1dCBk b2VzDQogICAgbm90IHByb3ZpZGUgYW55IHNvcnQgb2YgcmVwbGF5LXByb3RlY3Rpb24gaW4gYW5k IG9mIGl0c2VsZg0KICAgICgyKSB0byBjb252ZXkgdGhlIFJTLWdlbmVyYXRlZCBub25jZSBOMiBi YWNrIHRvIHRoZSBjbGllbnQgaW4gdGhlDQogICAgYXV0aHotaW5mbyByZXNwb25zZTsgdGhpcyBk b2VzIHNlcnZlIGFzIHJlcGxheSBwcm90ZWN0aW9uIGluIHNvbWUgc2Vuc2UsDQogICAgYnV0IGlu IHRoYXQgaXQgc2VydmVzIHRvIGNhdXNlIHJlcGVhdGVkIHBvc3Rpbmcgb2YgdGhlIHNhbWUgdG9r ZW4gKGFzDQogICAgbWlnaHQgb2NjdXIgaW4gYSByZXBsYXkgYXR0YWNrKSB0byBnZW5lcmF0ZSBh IGRpZmZlcmVudCBPU0NPUkUgY29udGV4dA0KICAgIChkdWUgdG8gdGhlIFJTZXMgY29udHJpYnV0 b3J5IG5hdHVyZSkgc28gdGhhdCB0aGUgcmVzdWx0aW5nIGtleSBtYXRlcmlhbA0KICAgIHdpbGwg YmUgdW5pcXVlIGZvciBhIGdpdmVuIGFzc29jaWF0aW9uLCBhcyBvcHBvc2VkIHRvIGRldGVjdGlu ZyBhbmQNCiAgICBibG9ja2luZyByZXBsYXkgb3V0cmlnaHQuICBJIHRoaW5rIGFsbCB0aHJlZSB1 c2VzIHNob3VsZCBoYXZlIGRpc3RpbmN0DQogICAgcGFyYW1ldGVyIG5hbWVzLCBiYXNlZCBvbiBt eSBjdXJyZW50IHVuZGVyc3RhbmRpbmcuDQogICAgDQpGUDogWWVzLCB5b3VyIHVuZGVyc3RhbmRp bmcgaXMgcmlnaHQuIEkgZG9uJ3Qgc2VlIGFueSBwcm9ibGVtIGF0IGFsbCB3aXRoIGRlZmluaW5n IG5ldyBwYXJhbWV0ZXJzIG5hbWVzIGZvciB0aGUgbm9uY2VzLCB0aGUgcmVhc29uIHdlIHVzZWQg ImNub25jZSIgaXMgdGhhdCB0aGlzIGV4YWN0IHBvaW50IHdhcyBicm91Z2h0IHVwIGluIHRoZSB3 ZyBhbmQgZXZlcnlib2R5IHNlZW1lZCB0byBhZ3JlZSBvbiBubyBuZWVkIHRvIGRlZmluZSBhIG5l dyBvbmUsIGRlc3BpdGUgdGhlIHNlbWFudGljcyBvZiAiY25vbmNlIi4gVGhlIGF1dGhvcnMgZGlk IG5vdCBoYXZlIGEgc3Ryb25nIG9waW5pb24uDQoNCjQuICAgIFdlIG1lbnRpb24gc2V2ZXJhbCB0 aW1lcyBhYm91dCBnZXR0aW5nIHByb3RlY3Rpb24gZnJvbSBBRUFEIG5vbmNlL2tleQ0KICAgIHJl dXNlLCBidXQgdG8gc29tZSBleHRlbnQgbGVhdmUgaXQgdG8gdGhlIHJlYWRlciB0byBmaWd1cmUg b3V0IGhvdyB0aGF0DQogICAgd29ya3MuICBTcGVjaWZpY2FsbHksIHRoZSBvbmx5IGd1aWRhbmNl IHdlIGdpdmUgb24gbm9uY2Ugc2VsZWN0aW9uIGlzDQogICAgZm9yIG91ciBOMSBhbmQgTjIgdGhh dCBnbyBpbnRvIHRoZSBNYXN0ZXIgU2FsdDsgd2UgZG9uJ3Qgc2F5IGhvdyB2YXJ5aW5nDQogICAg dGhlIE1hc3RlciBTYWx0IGxpa2UgdGhhdCB3aWxsIGNhdXNlIHRoZSBnZW5lcmF0ZWQga2V5cyBh bmQgKGNvbW1vbikgSVZzDQogICAgdG8gZGlmZmVyIGFjcm9zcyBydW5zLCB0aHVzIGJ5IGNvbnN0 cnVjdGlvbiBwcmV2ZW50aW5nIHRoZSBjb2xsaXNpb24gb2YNCiAgICAoa2V5LCBub25jZSkgcGFp cnMuICAoSW1wbGVtZW50YXRpb24gY2FyZWxlc3NuZXNzIHRoYXQganVzdCByZXVzZXMNCiAgICBr ZXkrbm9uY2UgZm9yIGEgZ2l2ZW4gU2VjdXJpdHkgQ29udGV4dCBpcyBzdGlsbCBwb3NzaWJsZSwg b2YgY291cnNlLikNCiAgICANCkZQOiBXb3VsZCBpdCBiZSBzdWZmaWNpZW50IHRvIGFkZCBhIHNl bnRlbmNlIGluIFNlY3Rpb24gMiBzYXlpbmcgdGhhdCBieSBjb25zdHJ1Y3Rpb24gaWYgTWFzdGVy IFNhbHQgaXMgZGlmZmVyZW50IHRoYXQgd2lsbCBnZW5lcmF0ZSBkaWZmZXJlbnQga2V5cyBhbmQg Y29tbW9uIElWcyAoKyByZWZlcmVuY2UgdG8gT1NDT1JFKT8gRm9yIGV4YW1wbGUgaW4gdGhpcyBw YXJhZ3JhcGg6DQoNCiAgIEluIGZhY3QsIGJ5IHVzaW5nIHJhbmRvbSBub25jZXMgYXMgcGFydA0K ICAgb2YgdGhlIE1hc3RlciBTYWx0LCB0aGUgcmVxdWVzdCB0byB0aGUgYXV0aHotaW5mbyBlbmRw b2ludCBwb3N0aW5nDQogICB0aGUgc2FtZSB0b2tlbiByZXN1bHRzIGluIGEgZGlmZmVyZW50IFNl Y3VyaXR5IENvbnRleHQsIHNpbmNlIE1hc3Rlcg0KICAgU2VjcmV0LCBTZW5kZXIgSUQgYW5kIFJl Y2lwaWVudCBJRCBhcmUgdGhlIHNhbWUgYnV0IE1hc3RlciBTYWx0IGlzDQogICBkaWZmZXJlbnQu DQoNCjUuICAgIEluIGEgcmVsYXRlZCB2ZWluLCB3ZSBkbyBub3QgZ2V0IGludG8gZnVsbCBkZXRh aWwgYWJvdXQgdGhlDQogICAgY3J5cHRvZ3JhcGhpYyByb2xlIHBsYXllZCBieSBOMSBhbmQgTjIs IHNvIGFzIHRvIG1ha2UgdGhlIHJlYWRlcg0KICAgIGNvbmZpZGVudCB0aGF0IG91ciA2NC1iaXQg cmVjb21tZW5kYXRpb24gZG9lcyBwcm92aWRlIGZ1bGwNCiAgICBJbnRlcm5ldC1ncmFkZSBzZWN1 cml0eSAoYXMgb3Bwb3NlZCB0byBhIHdlYWtlbmVkICJJb1QiIHZhcmlhbnQpLiAgSSdtDQogICAg bm90IHNwZWNpZmljYWxseSBjb25jZXJuZWQsIGJ1dCB3ZSBtYXkgZ2V0IHNvbWUgcmV2aWV3ZXJz IGFza2luZyBmb3INCiAgICBtb3JlIGRldGFpbC4NCiAgICANCkZQOiB3b3VsZCBpdCBiZSBzdWZm aWNpZW50IHRvIGFkZCB0ZXh0IGFsb25nIHRoZSBsaW5lcyBvZiB3aGF0IHlvdSBkZXNjcmliZSBp biBwb2ludCAzIGFib3ZlPw0KDQo2LiAgICBJIGFtLCBob3dldmVyLCBjb25jZXJuZWQgYWJvdXQg dGhlIGV4cG9zdXJlIHRvIGFuIFJGQyAzNTUyLXN0eWxlDQogICAgYXR0YWNrZXIgZm9yIHVucHJv dGVjdGVkIGF1dGh6LWluZm8gcmVzcG9uc2VzLiAgVGhlcmUgYXJlIHR3byBtYWluDQogICAgYXNw ZWN0cyBJJ20gY29uY2VybmVkIGFib3V0OiBpZGVudGlmaWVyIHNlbGVjdGlvbiBhbmQgbm9uY2Ug c2VsZWN0aW9uLg0KICAgIExldHRpbmcgdGhlIHNlcnZlciBvdmVycmlkZSB0aGUgY2xpZW50J3Mg aWRlYSBvZiBpdHMgb3duIGlkZW50aXR5IChldmVuDQogICAgd2hlbiB0aGUgQVMgaGFzIGdpdmVu IHRoZSBjbGllbnQgYW4gaWRlbnRpZmllciEpIHNlZW1zIHRvIGluY3JlYXNlIHRoZQ0KICAgIHJp c2sgb2YgYSBjbGllbnQgYmVpbmcgdHJpY2tlZCBpbnRvIGltcGVyc29uYXRpbmcgYSBkaWZmZXJl bnQgY2xpZW50LA0KICAgIGFuZCB0aGUgc3RhdGVkIGp1c3RpZmljYXRpb24gKGxldHRpbmcgdGhl IFJTIHByZXNlcnZlIHVuaXF1ZW5lc3MpDQogICAgZG9lc24ndCBzZWVtIHRvIGhvbGQgdXAgaW4g b3VyIG9uZS1BUy1wZXItUlMgc3RhdGVkIHNjb3BlLCB3aGVyZSB0aGUgQVMNCiAgICBjYW4gZXF1 YWxseSB3ZWxsIGRvIHNvLiAgQmFzZWQgb24gd2hhdCBJIGtub3cgcmlnaHQgbm93LCBpdCBkb2Vz bid0IGZlZWwNCiAgICBsaWtlIHdlJ3JlIGF0IHRoZSByaWdodCBwb2ludCBvbiB0aGUgY29zdC9i ZW5lZml0IGN1cnZlLiAgRm9yIHRoZSBub25jZQ0KICAgIHNlbGVjdGlvbiwgdGhpcyBjb21lcyBp bnRvIHBsYXkgZHVlIHRvIHRoZSBsYWNrIG9mIGluamVjdGl2aXR5IGZvciB0aGUNCiAgICBtYXBw aW5nIG9mIGluaXRpYWwgQVMtZ2VuZXJhdGVkIHNhbHQsIE4xLCBhbmQgTjIgaW50byB0aGUgTWFz dGVyIFNhbHQuDQogICAgU3BlY2lmaWNhbGx5LCBpZiBhIGNsaWVudCBjaG9vc2VzIGFuIE4xIHRo YXQncyBhIHByZWZpeCBvZiBzb21lIG90aGVyIE4xDQogICAgdGhhdCB3YXMgdXNlZCwgdGhlbiB0 aGUgYXR0YWNrZXIgY2FuIHNlbmQgYW4gIk4yIiB0aGF0IGNvbnRhaW5zIHRoZSB0YWlsDQogICAg ZW5kIG9mIHRoYXQgb3RoZXIgTjEgcGx1cyB0aGUgYWN0dWFsIE4yIHBpY2tlZCBieSB0aGUgc2Vy dmVyIGluIHRoYXQNCiAgICBvdGhlciBleGNoYW5nZSwgY2F1c2luZyBhIGZ1bGwgbm9uY2UgY29s bGlzaW9uIGFuZCBoYXZpbmcgdGhlDQogICAgQVMtZ2VuZXJhdGVkIHBvcnRpb24gYmUgdGhlIG9u bHkgZGlmZmVyZW5jZSBpbiBNYXN0ZXIgU2FsdCBiZXR3ZWVuDQogICAgc2VjdXJpdHkgY29udGV4 dHMuICBVc2luZyBhIGxlbmd0aCBwcmVmaXggZm9yIHRoZSBmaWVsZHMgYmVpbmcNCiAgICBjb25j YXRlbmF0ZWQgcHJvdmlkZXMgaW5qZWN0aXZpdHkgYW5kIHRod2FydHMgdGhpcyB0eXBlIG9mIGF0 dGFjay4NCiAgICANCkZQOiBDb25jZXJuaW5nIGlkZW50aWZpZXIgc2VsZWN0aW9uOiBhZnRlciBh IG51bWJlciBvZiBwb2ludHMgcmFpc2VkIChoZXJlIGFuZCBpbiBmb2xsb3dpbmcgcG9pbnRzKSwg SSBkbyBiZWxpZXZlIHRoYXQgdGhlIG1lY2hhbmlzbSBvZiBsZXR0aW5nIHRoZSBSUyBwaWNrIHRo ZSBpZGVudGlmaWVyIG9mIHRoZSBjbGllbnQgaXMgbm90IHdvcnRoIHRoZSBhZGRpdGlvbmFsIGNv bXBsZXhpdHkuIFNvIEkgcHJvcG9zZSB3ZSByZXZlcnQgdGhhdCwgYW5kIGdvIGJhY2sgdG8gQVMg TVVTVCBwaWNrIHRoZSBjbGllbnRJZCwgdGhlIGNsaWVudElkIE1VU1QgYmUgaW5jbHVkZWQgaW4g dGhlIHRva2VuLiBUaGlzIHdpbGwgb25seSBhZGQgc29tZSBjb25zaWRlcmF0aW9ucyBhYm91dCB0 aGUgc2NlbmFyaW8gaGFzIHNldmVyYWwtQVMtcGVyLVJTLCBpbiB3aGljaCBjYXNlIHRoZXNlIEFT IG5lZWQgdG8gYmUgc3luY2hyb25pemVkIG9uIGNsaWVudElkcyB0aGV5IGdpdmUgb3V0LiANCkFi b3V0IG5vbmNlIHNlbGVjdGlvbjogd2Ugd2lsbCBkZWZpbmUgTjEgYW5kIE4yIGFzIENCT1IgYnN0 ciwgc28gdGhhdCB0aGUgbGVuZ3RoIHByZWZpeCB3aWxsIGJlIGluY2x1ZGVkLg0KDQo3LiAgICBU aGVyZSBhcmUgYSBmZXcgcGxhY2VzIHdoZXJlIEknbSBub3QgZW50aXJlbHkgc3VyZSBob3cgdGhl IHByb3RvY29sIGZsb3cNCiAgICB3b3JrcyBmb3IgdGhlIGNhc2Ugd2hlcmUgdGhlIFJTIGlzIChy ZSlhc3NpZ25pbmcgdGhlIGNsaWVudElkOyBJJ3ZlDQogICAgdHJpZWQgdG8gbm90ZSB0aGVtIGlu IHRoZSBzZWN0aW9uLWJ5LXNlY3Rpb24gY29tbWVudHMuDQogICAgDQpGUDogWWVzLCBJIGFncmVl LCB3ZSBtaXNzZWQgc29tZSBvZiB0aG9zZS4gQXMgbWVudGlvbmVkLCBJIHRoaW5rIGl0IGNvdWxk IGJlIHNvbHZlZCwgYnV0IHRoZSBhZGRpdGlvbmFsIGNvbXBsZXhpdHkgaXMgcHJvYmFibHkgbm90 IHdvcnRoIGl0Lg0KDQogICAgT24gdG8gdGhlIHNlY3Rpb24tYnktc2VjdGlvbiBub3RlczoNCiAg ICANCiAgICBTZWN0aW9uIDENCiAgICANCjguICAgIEknZCBzdWdnZXN0IG5vdGluZyB0aGF0IHRo aXMgaXMgYSBzeW1tZXRyaWMtY3J5cHRvLWJhc2VkIHNjaGVtZSBpbiBzb21lDQogICAgbWFubmVy IChlLmcuLCB0aGF0IHRoZSBBUyBpcyBhc3NpZ25pbmcgYSBzaGFyZWQgc3ltbWV0cmljIGtleSB1 c2VkIGFzIHRoZQ0KICAgIE9TQ09SRSBtYXN0ZXIgc2VjcmV0KSwgYW5kL29yIHRoYXQgYXN5bW1l dHJpYyBQb1Agc2VtYW50aWNzIGFyZSBub3QgcG9zc2libGUNCiAgICB3aXRoIHRoaXMgbWVjaGFu aXNtIChvciBPU0NPUkUgaW4gZ2VuZXJhbCkuDQoNCkZQOiBPSw0KICAgIA0KOS4gICAgSSdkIGFs c28gc3VnZ2VzdCBub3RpbmcgdGhhdCBwcm9vZiBvZiBwb3NzZXNzaW9uIGlzIG5vdCBkb25lIGJ5 IGEgZGVkaWNhdGVkDQogICAgcHJvdG9jb2wgZWxlbWVudCwgYnV0IHJhdGhlciBvY2N1cnMgaW1w bGljaXRseSBiYXNlZCBvbiBrbm93bGVkZ2Ugb2YgdGhlDQogICAgT1NDT1JFIFNlY3VyaXR5IENv bnRleHQuICAoVGhpcyBpcyBlc3NlbnRpYWxseSBhbmFsb2dvdXMgdG8gS2VyYmVyb3MsIGJ1dCBh DQogICAgcmVmZXJlbmNlIGlzIG5vdCBzdHJpY3RseSBuZWVkZWQuKSAgV2UgZG8gaGF2ZSBhIGdv b2QgdHJlYXRtZW50IGluDQogICAgdG9wbGV2ZWwgU2VjdGlvbiA0LCBidXQgaXQgbWlnaHQgYmUg d29ydGggc2F5aW5nIGVhcmxpZXIuDQogICAgDQpGUDogT0sNCg0KICAgIFNlY3Rpb24gMg0KICAg IA0KMTAuICAgICAgIFtJLUQuaWV0Zi1hY2Utb2F1dGgtYXV0aHpdLiAgVGhlIGFjY2VzcyB0b2tl biByZXF1ZXN0IGFuZCByZXNwb25zZQ0KICAgICAgIE1VU1QgYmUgY29uZmlkZW50aWFsaXR5LXBy b3RlY3RlZCBhbmQgZW5zdXJlIGF1dGhlbnRpY2l0eS4gIFRoaXMNCiAgICAgICBwcm9maWxlIFJF Q09NTUVORFMgdGhlIHVzZSBvZiBPU0NPUkUgYmV0d2VlbiBjbGllbnQgYW5kIEFTLCBidXQgVExT DQogICAgICAgb3IgRFRMUyBNQVkgYmUgdXNlZCBhZGRpdGlvbmFsbHkgb3IgaW5zdGVhZC4NCiAg ICANCiAgICBTaW5jZSB0aGUgY2xpZW50L0FTIGFuZCBjbGllbnQvUlMgcHJvZmlsZSBhcmUgc3Vw cG9zZWQgdG8gYmUgY29tcGxldGVseQ0KICAgIHNldmVyYWJsZSwgSSBkb24ndCB0aGluayB3ZSBz aG91bGQgdXNlICJNQVkiIGhlcmU7IHBlcmhhcHMgImJ1dCBvdGhlcg0KICAgIHByb3RvY29scyAo c3VjaCBhcyBUTFMgb3IgRFRMUykgY2FuIGJlIHVzZWQgYXMgd2VsbCIuDQogICAgDQpGUDogT0sN Cg0KMTEuICAgICAgIE9uY2UgdGhlIGNsaWVudCBoYXMgcmV0cmlldmVkIHRoZSBhY2Nlc3MgdG9r ZW4sIGl0IGdlbmVyYXRlcyBhIG5vbmNlDQogICAgICAgTjEgYW5kIHBvc3RzIGJvdGggdGhlIHRv a2VuIGFuZCBOMSB0byB0aGUgUlMgdXNpbmcgdGhlIGF1dGh6LWluZm8NCiAgICAgICBlbmRwb2lu dCBhbmQgbWVjaGFuaXNtcyBzcGVjaWZpZWQgaW4gc2VjdGlvbiA1Ljggb2YNCiAgICAgICBbSS1E LmlldGYtYWNlLW9hdXRoLWF1dGh6XSBhbmQgQ29udGVudC1Gb3JtYXQgPSBhcHBsaWNhdGlvbi9h Y2UrY2Jvci4NCiAgICANCiAgICBEbyB3ZSB3YW50IHRvIHNheSBleHBsaWNpdGx5IHRoYXQgdGhl cmUgaXMgbm8gY3J5cHRvZ3JhcGhpYyBwcm90ZWN0aW9uDQogICAgYXBwbGllZCBmb3IgdGhpcyBQ T1NUIHRvIGF1dGh6LWluZm8/DQoNCkZQOiBPSyAod2lsbCBhZGQgYSBub3RlKQ0KICAgIA0KMTIu ICAgICAgIHdoaWNoIGNvbnRhaW5zIGEgbm9uY2UgTjIgaW4gYSBDQk9SIG1hcC4gIE1vcmVvdmVy LCB0aGUgc2VydmVyDQogICAgICAgY29uY2F0ZW5hdGVzIE4xIHdpdGggTjIgYW5kIGFwcGVuZHMg dGhlIHJlc3VsdCB0byB0aGUgTWFzdGVyIFNhbHQgaW4NCiAgICAgICB0aGUgU2VjdXJpdHkgQ29u dGV4dCAoc2VlIHNlY3Rpb24gMyBvZg0KICAgICAgIFtJLUQuaWV0Zi1jb3JlLW9iamVjdC1zZWN1 cml0eV0pLiAgVGhlIFJTIHRoZW4gZGVyaXZlcyB0aGUgY29tcGxldGUNCiAgICAgICBTZWN1cml0 eSBDb250ZXh0IGFzc29jaWF0ZWQgd2l0aCB0aGUgcmVjZWl2ZWQgdG9rZW4gZnJvbSBpdCBwbHVz IHRoZQ0KICAgICAgIHBhcmFtZXRlcnMgcmVjZWl2ZWQgaW4gdGhlIEFTLCBmb2xsb3dpbmcgc2Vj dGlvbiAzLjIgb2YNCiAgICAgICBbSS1ELmlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHldLg0KICAg IA0KICAgIFRoaXMgcGFzc2FnZSBmZWVscyBzdHJhbmdlIHRvIG1lLCBwcm9iYWJseSBiZWNhdXNl IGl0IHNlZW1zIHRvIHVzZSAiTWFzdGVyDQogICAgU2FsdCIgdG8gYm90aCB0aGUgcG9ydGlvbiB3 aXRoIGFuZCB3aXRob3V0IE4xK04yLCBhbmQgYWxzbyBiZWNhdXNlIGl0IGRvZXMNCiAgICBub3Qg aW50cm9kdWNlICJ0aGUgTWFzdGVyIFNhbHQiIGFzIGEgdGVybSBvciBzb21lIG90aGVyIG9iamVj dCB0aGF0IGRlc2VydmVzDQogICAgdGhlIGRlZmluaXRlIGFydGljbGUuICBXb3VsZCBpdCBiZSBl cXVpdmFsZW50IHRvIHNheSAiTW9yZW92ZXIsIHRoZSBzZXJ2ZXINCiAgICBjb25jYXRlbmF0ZXMg dGhlIGlucHV0IHNhbHQsIE4xLCBhbmQgTjIgdG8gb2J0YWluIHRoZSBNYXN0ZXIgU2FsdCBvZiB0 aGUNCiAgICBPU0NPUkUgU2VjdXJpdHkgQ29udGV4dCAoc2VlIHNlY3Rpb24gMyBvZiBbSS1ELmll dGYtY29yZS1vYmplY3Qtc2VjdXJpdHldIg0KICAgIGluc3RlYWQ/ICAoVGhvdWdoIHRoZSBkZXRh aWxzIG1heSB5ZXQgY2hhbmdlIGJhc2VkIG9uIGxhdGVyIGNvbW1lbnRzLi4uKQ0KICAgIElzICJm cm9tIGl0IiB0aGUgcmVzdWx0aW5nIE1hc3RlciBTYWx0Pw0KICAgIFRoZXJlIHNlZW1zIHRvIGJl IGEgd29yZCBvciB0d28gbWlzc2luZyBpbiAidGhlIHBhcmFtZXRlcnMgcmVjZWl2ZWQgaW4NCiAg ICB0aGUgQVMiLiAgKFByZXN1bWFibHkgdGhlc2UgcGFyYW1ldGVycyBhcmUgY29udGFpbmVkIGlu IHRoZSB0b2tlbj8pDQogICAgDQpGUDogT0suIFllcyx0aGF0IHdvdWxkIGJlIGVxdWl2YWxlbnQu IFllcywgIkZyb20gaXQiIHJlZmVycmVkIHRvIHRoZSBNYXN0ZXIgU2FsdCAodGhlIGlucHV0IHNh bHQgY29uY2F0ZW5hdGVkIHdpdGggTjEgYW5kIE4yKS4gWWVzLCBpdCdzIG1pc3NpbmcgInJlY2Vp dmVkIGluIHRoZSBhY2Nlc3MgdG9rZW4gZnJvbSB0aGUgQVMiLg0KDQoxMy4gICAgICAgQWZ0ZXIg cmVjZWl2aW5nIHRoZSBub25jZSBOMiwgdGhlIGNsaWVudCBjb25jYXRlbmF0ZXMgaXQgd2l0aCBO MSBhbmQNCiAgICAgICBhcHBlbmRzIHRoZSByZXN1bHQgdG8gdGhlIE1hc3RlciBTYWx0IGluIGl0 cyBTZWN1cml0eSBDb250ZXh0IChzZWUNCiAgICAgICBzZWN0aW9uIDMgb2YgW0ktRC5pZXRmLWNv cmUtb2JqZWN0LXNlY3VyaXR5XSkuICBUaGUgY2xpZW50IHRoZW4NCiAgICAgICBkZXJpdmVzIHRo ZSBjb21wbGV0ZSBTZWN1cml0eSBDb250ZXh0IGZyb20gdGhlIG5vbmNlcyBwbHVzIHRoZQ0KICAg ICAgIHBhcmFtZXRlcnMgcmVjZWl2ZWQgZnJvbSB0aGUgQVMuDQogICAgDQogICAgU2ltaWxhcmx5 LCBJSVVDIHdlIHNob3VsZCBiZSBhYmxlIHRvIHdvcmQgdGhpcyBzbyB0aGF0IHRoZSAiTWFzdGVy IFNhbHQiIGlzDQogICAgdW5pcXVlIChhbmQgaW5jbHVkZXMgdGhlIG5vbmNlcyksIGFzIG9wcG9z ZWQgdG8gaGF2aW5nIGl0IGFwcGFyZW50bHkgcmVmZXIgdG8NCiAgICBib3RoIHRoZSBwcmUtIGFu ZCBwb3N0LW5vbmNlLWluY2x1ZGlvbiBzdHJpbmdzLg0KICAgIEFyZSB0aGVzZSAicGFyYW1ldGVy cyIgcmVjZWl2ZWQgZnJvbSB0aGUgQVMgaW4gdGhlIHRva2VuIHJlc3BvbnNlPw0KICAgIA0KRlA6 IE9LLiBZZXMsIHRoZXkgYXJlLg0KDQoxNC4gICAgICAgRmluYWxseSwgdGhlIGNsaWVudCBzZW5k cyBhIHJlcXVlc3QgcHJvdGVjdGVkIHdpdGggT1NDT1JFIHRvIHRoZSBSUy4NCiAgICAgICBJZiB0 aGUgcmVxdWVzdCB2ZXJpZmllcywgdGhlbiB0aGlzIFNlY3VyaXR5IENvbnRleHQgaXMgc3RvcmVk IGluIHRoZQ0KICAgICAgIHNlcnZlciwgYW5kIHVzZWQgaW4gdGhlIHJlc3BvbnNlLCBhbmQgaW4g ZnVydGhlciBjb21tdW5pY2F0aW9ucyB3aXRoDQogICAgICAgdGhlIGNsaWVudCwgdW50aWwgdG9r ZW4gZXhwaXJhdGlvbi4gIFRoaXMgU2VjdXJpdHkgQ29udGV4dCBpcw0KICAgICAgIGRpc2NhcmRl ZCBpZiB0aGUgc2FtZSB0b2tlbiBpcyByZS11c2VkIHRvIHN1Y2Nlc3NmdWxseSBkZXJpdmUgYSBu ZXcNCiAgICAgICBTZWN1cml0eSBDb250ZXh0Lg0KICAgIA0KICAgIFRoZSBjb25kaXRpb25hbCBv biBzdG9yaW5nIHRoZSBTZWN1cml0eSBDb250ZXh0IG9ubHkgaWYgdGhlIHJlcXVlc3QNCiAgICB2 ZXJpZmllcyByZWFkcyBvZGRseSB0byBtZSwgYXMgdGhlIFJTIHNlZW1zIHRvIGhhdmUgbmVlZGVk IHRvIHN0b3JlIHNvbWUNCiAgICBhbW91bnQgb2Ygc2VjdXJpdHkgY29udGV4dCBpbmZvcm1hdGlv biBmb3IgdGhlIHBlcmlvZCBiZXR3ZWVlbiByZWNlaXZpbmcNCiAgICB0aGUgdG9rZW4gYW5kIHJl Y2VpdmluZyB0aGUgYXV0aGVudGljYXRlZCByZXF1ZXN0LCBhcyBhIHByZXJlcXVpc2l0ZSB0bw0K ICAgIGJlaW5nIGFibGUgdG8gdmVyaWZ5IHRoZSByZXF1ZXN0Lg0KICAgIEFsc28sIGlzIHRoaXMg c2VjdXJpdHkgY29udGV4dCBkaXNjYXJkZWQgaWYgYSBuZXcgdG9rZW4gZnJvbSB0aGUgc2FtZQ0K ICAgIGNsaWVudCBpcyBzdWNjZXNzZnVsbHkgdXNlZD8NCg0KRlA6ICJTdG9yaW5nIiBpcyBwcm9i YWJseSBub3QgY2xlYXIgZW5vdWdoLCB0aGUgcG9pbnQgaXMgdGhhdCBvbmx5IGFmdGVyIHRoZSBy ZXF1ZXN0IHBhc3NlcyB2ZXJpZmljYXRpb24gdGhlIHNlcnZlciBtYXJrcyB0aGlzIHNlY3VyaXR5 IGNvbnRleHQgYXMgInZhbGlkIiBmb3IgdGhpcyBjbGllbnQuIEknZCBsb3ZlIHN1Z2dlc3Rpb25z IG9uIGhvdyB0byBtYWtlIHRoaXMgY2xlYXJlci4gWWVzLCB0aGUgc2VjdXJpdHkgY29udGV4dCBp cyBkaXNjYXJkZWQgaWYgYSBuZXcgdG9rZW4gKG9yIGEgdmFsaWQgb2xkIG9uZSkgaXMgc3VjY2Vz c2Z1bGx5IHVzZWQuIElzIGFueXRoaW5nIG1pc3NpbmcgaGVyZT8NCiAgICANCjE1LiAgICAgICBU aGUgdXNlIG9mIHJhbmRvbSBub25jZXMgZHVyaW5nIHRoZSBleGNoYW5nZSBwcmV2ZW50cyB0aGUg cmV1c2Ugb2YNCiAgICAgICBBRUFEIG5vbmNlcyBhbmQga2V5cyB3aXRoIGRpZmZlcmVudCBtZXNz YWdlcywgaW4gY2FzZSBvZiByZS0NCiAgICAgICBkZXJpdmF0aW9uIG9mIHRoZSBTZWN1cml0eSBD b250ZXh0IGJvdGggZm9yIENsaWVudHMgYW5kIFJlc291cmNlDQogICAgICAgU2VydmVycyBmcm9t IGFuIG9sZCBub24tZXhwaXJlZCBhY2Nlc3MgdG9rZW4sIGUuZy4gaW4gY2FzZSBvZiByZS1ib290 DQogICAgICAgb2YgZWl0aGVyIHRoZSBjbGllbnQgb3IgUlMuICBJbiBmYWN0LCBieSB1c2luZyBy YW5kb20gbm9uY2VzIGFzIHBhcnQNCiAgICANCiAgICBUaGlzIHNlbnRlbmNlIGlzIHByZXR0eSBs b25nIGFuZCBhIGxpdHRsZSBoYXJkIHRvIHBhcnNlLiAgSSdkIHN1Z2dlc3QNCiAgICBzb21ldGhp bmcgbW9yZSBsaWtlOg0KICAgIA0KICAgICUgIFRoZSB1c2Ugb2YgcmFuZG9tIG5vbmNlcyBkdXJp bmcgdGhlIGV4Y2hhbmdlIHByZXZlbnRzIHRoZSByZXVzZSBvZg0KICAgICUgIGFuIEFFQUQgbm9u Y2VzL2tleSBwYWlyIGZvciB0d28gZGlmZmVyZW50IG1lc3NhZ2VzLiAgVGhpcyBzaXR1YXRpb24N CiAgICAlICBtaWdodCBvY2N1ciB3aGVuIGNsaWVudCBhbmQgUlMgZGVyaXZlIGEgbmV3IFNlY3Vy aXR5IENvbnRleHQgZnJvbSBhbg0KICAgICUgIGV4aXN0aW5nIChub24tZXhwaXJlZCkgYWNjZXNz IHRva2VuLCBhcyBtaWdodCBvY2N1ciB3aGVuIGVpdGhlciBwYXJ0eQ0KICAgICUgIGhhcyBqdXN0 IHJlYm9vdGVkLiAgWy4uLl0NCiAgICANCkZQOiBPSw0KDQogICAgSSdkIGFsc28gY29uc2lkZXIg cy9JbiBmYWN0L0luc3RlYWQvIHNpbmNlIHdlIGFyZSBjb250cmFzdGluZyB0aGUNCiAgICBwcmV2 aW91c2x5IGRlc2NyaWJlZCBoeXBvdGhldGljYWwgKGJhZCkgc2NlbmFyaW8gd2l0aCB3aGF0IGFj dHVhbGx5DQogICAgaGFwcGVucy4NCiAgICANCkZQOiBPSw0KDQoxNi4gICAgICAgb2YgdGhlIE1h c3RlciBTYWx0LCB0aGUgcmVxdWVzdCB0byB0aGUgYXV0aHotaW5mbyBlbmRwb2ludCBwb3N0aW5n DQogICAgICAgdGhlIHNhbWUgdG9rZW4gcmVzdWx0cyBpbiBhIGRpZmZlcmVudCBTZWN1cml0eSBD b250ZXh0LCBzaW5jZSBNYXN0ZXINCiAgICAgICBTZWNyZXQsIFNlbmRlciBJRCBhbmQgUmVjaXBp ZW50IElEIGFyZSB0aGUgc2FtZSBidXQgTWFzdGVyIFNhbHQgaXMNCiAgICAgICBkaWZmZXJlbnQu ICBUaGVyZWZvcmUsIHRoZSBtYWluIHJlcXVpcmVtZW50IGZvciB0aGUgbm9uY2VzIGlzIHRoYXQN CiAgICANCiAgICBuaXQ6IFttb3JlIHVzYWdlIG9mICJNYXN0ZXIgU2FsdCIgZm9yIHByZS0gYW5k IHBvc3Qtbm9uY2UgZm9ybXNdDQogICAgSSdkIGFsc28gc3VnZ2VzdCB0byBzL3NpbmNlL3NpbmNl IGV2ZW4gdGhvdWdoIHRoZS8gKGFuZCB0aGUgcy9idXQvdGhlLw0KICAgIG5lZWRlZCB0byBmaXgg dXAgdGhlIGVuZCBvZiB0aGUgc2VudGVuY2UpLg0KDQpGUDogT0sgKHJlZm9ybXVsYXRpb24gYWxy ZWFkeSBmaXhlZCBpbiBQUikNCiAgICANCiAgICBJIGFsc28gd2FudCB0byBjaGVjayBteSB1bmRl cnN0YW5kaW5nOiB0aGlzICJkaWZmZXJlbnQgU2VjdXJpdHkgQ29udGV4dCIgaXMNCiAgICBzdGls bCBnb2luZyB0byB1c2UgdGhlIHNhbWUgaWRlbnRpZmllcnMgZm9yIHRoZSBlbmRwb2ludHMsIGFu ZCB3aWxsIGp1c3QgaGF2ZQ0KICAgIGRpZmZlcmVudCBrZXlzL0lWcy9ldGM/ICBUaGlzIHdvdWxk IHRpZSBpbiB0byB0aGUgKGxhdGVyKSByZWNvbW1lbmRhdGlvbiB0bw0KICAgIGhhdmUgc3VjaCBh IG5ldyBTZWN1cml0eSBDb250ZXh0IGNvbXBsZXRlbHkgcmVwbGFjZSB0aGUgb2xkIG9uZSwgc2lu Y2UNCiAgICBvdGhlcndpc2Ugd2UnZCBoYXZlIHRvIHJlc29ydCB0byB0cmlhbCBkZWNyeXB0aW9u IHRvIGRldGVybWluZSB3aGljaA0KICAgIFNlY3VyaXR5IENvbnRleHQgdG8gdXNlIGZvciBwcm9j ZXNzaW5nIGEgZ2l2ZW4gbWVzc2FnZS4NCiAgICANCkZQOiBZZXMsIGl0IHdvdWxkIHVzZSB0aGUg c2FtZSBpZGVudGlmaWVycy4gVHlwaWNhbGx5LCB0aGUgb2xkIHNlY3VyaXR5IGNvbnRleHQgd291 bGQgZ2V0IGRpc2NhcmRlZCB3aGVuIHRoZSBuZXcgb25lIGlzIHZhbGlkYXRlZC4gQXBwbGljYXRp b25zIGNvdWxkIHN0aWxsIGRlY2lkZSB0byBrZWVwIG1vcmUgdGhhbiBvbmUgY29udGV4dCwgYW5k IGluIHRoYXQgY2FzZSB5ZXMsIHRoZXknZCBoYXZlIHRvIHJlbHkgb24gdHJpYWwgZGVjcnlwdGlv biwgYnV0IHRoYXQgaXMgbm90IHRoZSBnb2FsIG9mIHRoaXMgZG9jdW1lbnQuDQoNCjE3LiAgICAg ICB0aGV5IGhhdmUgYSBnb29kIGFtb3VudCBvZiByYW5kb21uZXNzLiAgSWYgcmFuZG9tIG5vbmNl cyB3ZXJlIG5vdA0KICAgICAgIHVzZWQsIGEgbm9kZSByZS11c2luZyBhIG5vbi1leHBpcmVkIG9s ZCB0b2tlbiB3b3VsZCBiZSBzdXNjZXB0aWJsZSB0bw0KICAgICAgIG9uLXBhdGggYXR0YWNrZXJz IHByb3Zva2luZyB0aGUgY3JlYXRpb24gb2YgT1NDT1JFIG1lc3NhZ2VzIHVzaW5nIG9sZA0KICAg ICAgIEFFQUQga2V5cyBhbmQgbm9uY2VzLg0KICAgIA0KICAgIEkgZ3Vlc3MgdGhlIGZvY3VzIG9u ICJnb29kIGFtb3VudCBvZiByYW5kb21uZXNzIiBpcyB0cnlpbmcgdG8gZW1waGFzaXplDQogICAg dGhhdCB3ZSBtZXJlbHkgbmVlZCB0byBhdm9pZCBhIHNpbmdsZSBub2RlIGFjY2lkZW50YWxseSBw cm9kdWNpbmcgdGhlDQogICAgc2FtZSB2YWx1ZSwgYXMgb3Bwb3NlZCB0byBhIHN0cmljdGVyIHBy b3BlcnR5IG9mIHVuZ3Vlc3NhYmlsaXR5IGJ5IGFuDQogICAgb24tcGF0aCBhdHRhY2tlcj8gIE9y IGlzIHVuZ3Vlc3NhYmlsaXR5IGFsc28gbmVlZGVkIHdoZW4gdGhlIGF0dGFja2VyDQogICAgY2Fu IGRlbGF5IHRyYWZmaWM/DQogICAgDQpGUDogWWVzLCB0aGF0IGlzIGNvcnJlY3QgKGFib3V0IHRo ZSBzaW5nbGUgbm9kZSkuIFdlIGRvIG5vdCB0aGluayB1bmd1ZXNzYWJpbGl0eSBpcyBuZWVkZWQu IERvIHlvdSB0aGluayBpdCBzaG91bGQ/DQoNCiAgICBTZWN0aW9uIDMNCiAgICANCjE4LiAgICAg ICBTZWN0aW9uIDMuMiBvZiBbSS1ELmlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHldIGRlZmluZXMg aG93IHRvIGRlcml2ZQ0KICAgICAgIGEgU2VjdXJpdHkgQ29udGV4dCBiYXNlZCBvbiBhIHNoYXJl ZCBtYXN0ZXIgc2VjcmV0IGFuZCBhIHNldCBvZiBvdGhlcg0KICAgICAgIHBhcmFtZXRlcnMsIGVz dGFibGlzaGVkIGJldHdlZW4gY2xpZW50IGFuZCBzZXJ2ZXIsIHdoaWNoIHRoZSBjbGllbnQNCiAg ICAgICByZWNlaXZlcyBmcm9tIHRoZSBBUyBpbiB0aGlzIGV4Y2hhbmdlLiAgVGhlIHByb29mLW9m LXBvc3Nlc3Npb24ga2V5DQogICAgDQogICAgV2Ugc2F5IHRoYXQgdGhlIGNsaWVudCBnZXRzIHRo ZSBPU0NPUkUgcGFyYW1ldGVycyBmcm9tIHRoZSBBUyBpbiB0aGUNCiAgICB0b2tlbiByZXNwb25z ZTsgd2hlcmUgZG8gd2Ugc2F5IGhvdyB0aGUgUlMgZ2V0cyB0aGUgT1NDT1JFIHBhcmFtZXRlcnMN CiAgICBmcm9tIHRoZSBBUz8NCiAgICANCkZQOiBEbyB5b3UgbWVhbiB0aGlzIHNlbnRlbmNlIGZy b20gc2VjdGlvbiA0Lg0KDQogICBUaGUNCiAgIGNsaWVudCBnZW5lcmF0ZXMgYSBub25jZSBOMSBh bmQgcG9zdHMgaXQgdG9nZXRoZXIgd2l0aCB0aGUgdG9rZW4gdGhhdA0KICAgaW5jbHVkZXMgdGhl IG1hdGVyaWFscyBwcm92aXNpb25lZCBieSB0aGUgQVMgdG8gdGhlIFJTLiANCg0KQW5kIGlmIG5v dCwgd2hhdCBhcmUgd2UgbWlzc2luZz8NCg0KICAgIFNlY3Rpb24gMy4xDQogICAgDQoxOS4gICAg ICAgVGhlIGNsaWVudCBNVVNUIHNlbmQgdGhpcyBQT1NUIHJlcXVlc3QgdG8gdGhlIHRva2VuIGVu ZHBvaW50IG92ZXIgYQ0KICAgICAgIHNlY3VyZSBjaGFubmVsIHRoYXQgZ3VhcmFudGVlcyBhdXRo ZW50aWNhdGlvbiwgbWVzc2FnZSBpbnRlZ3JpdHkgYW5kDQogICAgICAgY29uZmlkZW50aWFsaXR5 IChzZWUgU2VjdGlvbiA1KS4NCiAgICANCiAgICAoVGhlIGZyYW1ld29yayBhbHJlYWR5IHJlcXVp cmVzIHRoaXMsIHNvIHdlIG1heSBub3QgbmVlZCB0aGUgIk1VU1QiDQogICAga2V5d29yZCBhZ2Fp biwgdGhvdWdoIEknbSBub3QgcHJvcG9zaW5nIHRvIHJlbW92ZSBhbGwgbWVudGlvbiBvZiB0aGUN CiAgICBuZWVkIGZvciB0aGVzZSBwcm9wZXJ0aWVzLikNCg0KRlA6IE9LLCB3aWxsIHJlbW92ZSBu b3JtYXRpdmUgTVVTVCBldGMgZm9yIHRoZSByZXF1aXJlbWVudHMgY29taW5nIGZyb20gdGhlIGZy YW1ld29yay4NCiAgICANCjIwLiAgICAgICBBbiBleGFtcGxlIG9mIHN1Y2ggYSByZXF1ZXN0LCBp biBDQk9SIGRpYWdub3N0aWMgbm90YXRpb24gd2l0aG91dCB0aGUNCiAgICAgICB0YWcgYW5kIHZh bHVlIGFiYnJldmlhdGlvbnMgaXMgcmVwb3J0ZWQgaW4gRmlndXJlIDINCiAgICANCiAgICBuaXQ6 IG9ubHkgdGhlIHBheWxvYWQgaXMgdXNpbmcgQ0JPUiBkaWFnbm9zdGljIG5vdGF0aW9uOyB0aGUg aGVhZGVycyBhcmUNCiAgICB1c2luZyBDb0FQIG5vdGF0aW9uLg0KDQpGUDogRG9uZSBpbiBQUi4N CiAgICANCjIxLiAgICAgICBJZiB0aGUgY2xpZW50IHdhbnRzIHRvIHVwZGF0ZSBpdHMgYWNjZXNz IHJpZ2h0cyB3aXRob3V0IGNoYW5naW5nIGFuDQogICAgICAgZXhpc3RpbmcgT1NDT1JFIFNlY3Vy aXR5IENvbnRleHQsIGl0IE1VU1QgaW5jbHVkZSBpbiBpdHMgUE9TVCByZXF1ZXN0DQogICAgICAg dG8gdGhlIHRva2VuIGVuZHBvaW50IGEgcmVxX2NuZiBvYmplY3QuICBUaGUgcmVxX2NuZiBNVVNU IGluY2x1ZGUgYQ0KICAgICAgIGtpZCBmaWVsZCBjYXJyeWluZyBhIENCT1IgYXJyYXkgb2JqZWN0 IGNvbnRhaW5pbmcgdGhlIGNsaWVudCdzDQogICAgICAgaWRlbnRpZmllciAoYXNzaWduZWQgaW4g c2VjdGlvbiBTZWN0aW9uIDMuMikgYW5kIG9wdGlvbmFsbHkgdGhlDQogICAgICAgY29udGV4dCBp ZGVudGlmaWVyIChpZiBhc3NpZ25lZCBpbiBzZWN0aW9uIFNlY3Rpb24gMy4yKS4gIFRoZSBDQk9S DQogICAgDQogICAgSSdtIG5vdCBzdXJlIHRoZSBiZXN0IHdheSB0byB3cml0ZSBhIGNsZWFyIGRl c2NyaXB0aW9uIHRoYXQgaW5jbHVkZXMgdGhlDQogICAgImJzdHIiIGZyYW1pbmcgZm9yICJraWQi Lg0KDQpGUDogT0ssIGl0IGlzIG1pc3NpbmcgaGVyZSB0aGF0IHRoZSBDQk9SIGFycmF5IGlzIHdy YXBwZWQgaW4gYSBic3RyLiBJIGRpZCBtaXNzIHRoYXQgdGhlIGtpZCBpcyBhIENCT1IgYnN0ciBh bmQgbm90IGEgYnl0ZSBzdHJpbmcuDQoNCiAgICBBbHNvLCBuaXQ6IHRoZSAiYXNzaWduZWQiIGxh bmd1YWdlIGluIHRoZSBwYXJlbnRoZXRpY2FscyBmZWVscyB3ZWlyZCB0bw0KICAgIG1lLCBoZXJl Lg0KDQpGUDogV2h5PyB0aGUgdXNlIG9mICJhc3NpZ25lZCIgd2FzIHRvIGhpZ2hsaWdodCB0aGF0 IHRoYXQncyB0aGUgdmFsdWUgdGhlIEFTIGhhcyBzZXQgYW5kIGNvbW11bmljYXRlZCB0byB0aGUg Q2xpZW50LiBIb3cgY2FuIHdlIG1ha2UgaXQgY2xlYXJlcj8NCg0KICAgIFdoYXQncyB0aGUgd29y a2Zsb3cgd2hlbiB0aGUgUlMgaGFzIG92ZXJyaWRkZW4gdGhlIEFTJ3MgaWRlYSBvZiB0aGUNCiAg ICBjbGllbnRJZD8gIERvZXMgdGhlIGNsaWVudCBoYXZlIHRvIHJlbWVtYmVyIHRoZSBvcmlnaW5h bCBBUy1hc3NpZ25lZA0KICAgIGNsaWVudElkIGFuZCB1c2UgaXQgaGVyZSBpbnN0ZWFkIG9mIHRo ZSBSUy1hc3NpZ25lZCBvbmU/DQoNCkZQOiBHb29kIHBvaW50LCB3aGljaCB3ZSBkaWQgbm90IGV4 cGFuZCBvbi4gWWVzLCB0byBtYWtlIHRoaXMgbWVjaGFuaXNtIHdvcmsgKFJTIGNhbiBwaWNrIGFu IGlkZW50aWZpZXIgZm9yIHRoZSBjbGllbnQgKyBBUyBoYXMgYWxyZWFkeSBhc3NpZ25lZCBvbmUp IHRoZSBjbGllbnQgd291bGQgaGF2ZSB0byByZW1lbWJlciB0aGUgb3JpZ2luYWwgQVMtYXNzaWdu ZWQgY2xpZW50SUQgYW5kIHVzZSB0aGF0LiBPciB3ZSBzaG91bGQgZGVmaW5lIGEgbWVjaGFuaXNt IGZvciB0aGUgY2xpZW50IHRvIGNvbW11bmljYXRlIHRoZSBSUy1hc3NpZ25lZCBjbGllbnRJZCB0 byB0aGUgQVMuIFRoaXMgd291bGQgYmUgbmVjZXNzYXJ5IGFsc28gaW4gY2FzZSB0aGUgQVMgZGlk IG5vdCBhc3NpZ24gdGhlIGNsaWVudElkIGF0IGFsbC4gQWZ0ZXIgdGhpbmtpbmcgdGhpcyB0aHJv dWdoIEkgdGhpbmsgdGhpcyBjb21wbGljYXRpb24gbWFrZXMgdGhpcyBSUyBvdmVyd3JpdGluZyB0 aGUgY2xpZW50SWQgbWVjaGFuaXNtIG5vdCB3b3J0aCBoYXZpbmcuDQoNCiAgICANCjIyLiAgICAg ICBUaGVzZSBpZGVudGlmaWVycyBjYW4gYmUgdXNlZCBieSB0aGUgQVMgdG8gZGV0ZXJtaW5lIHRo ZSBzaGFyZWQNCiAgICAgICBzZWNyZXQgdG8gY29uc3RydWN0IHRoZSBwcm9vZi1vZi1wb3NzZXNz aW9uIHRva2VuIGFuZCB0aGVyZWZvcmUgTVVTVA0KICAgICAgIGlkZW50aWZ5IGEgc3ltbWV0cmlj IGtleSB0aGF0IHdhcyBwcmV2aW91c2x5IGdlbmVyYXRlZCBieSB0aGUgQVMgYXMgYQ0KICAgICAg IHNoYXJlZCBzZWNyZXQgZm9yIHRoZSBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIGNsaWVudCBh bmQgdGhlIFJTLg0KICAgIA0KICAgIG5pdDogSSBzdWdnZXN0IHMvc2hhcmVkIHNlY3JldCB0byBj b25zdHJ1Y3Qvc2hhcmVkIHNlY3JldCBib3VuZCB0by8NCiAgICANCkZQOiBEb25lIGluIFBSLg0K DQogICAgQWxzbywgSSB0aGluayB0aGUgQVMgd2lsbCBuZWVkIHRvIHVzZSBzb21lIG9mIHRoZSBv dGhlciB0b2tlbiByZXF1ZXN0DQogICAgcGFyYW1ldGVycyAoZS5nLiwgcmVxX2F1ZCkgaW4gb3Jk ZXIgdG8gZGV0ZXJtaW5lIHRoZSBjbGllbnQgYW5kIFJTIGZvcg0KICAgIHdoaWNoIGl0IG5lZWRz IHRvIHJldHJpZXZlIHRoZSBzaGFyZWQgUG9QIGtleS4gIFdlIG1pZ2h0IHdhbnQgdG8gbWVudGlv bg0KICAgIHRoYXQgYXMgd2VsbC4NCg0KRlA6IEkgYW0gbm90IHN1cmUgdGhhdCB3b3VsZCBiZSBu ZWVkZWQsIGluIHByaW5jaXBsZS4gSWYgdGhlIGNsaWVudCBzZW5kcyB0aGVtLCB0aGVuIHllcywg dGhleSBjb3VsZCBiZSB1c2VkIChhbmQgSSBjYW4gYWRkIHRleHQgY2xhcmlmeWluZyB0aGF0KSwg YnV0IGlmIGl0IGRvZXNuJ3QsIHRob3NlIGlkZW50aWZpZXJzIHNob3VsZCBiZSBlbm91Z2guDQog ICAgDQoyMy4gICAgICAgVGhlIEFTIE1VU1QgdmVyaWZ5IHRoYXQgdGhlIHJlY2VpdmVkIHZhbHVl IGlkZW50aWZpZXMgYSBwcm9vZi1vZi0NCiAgICAgICBwb3NzZXNzaW9uIGtleSBhbmQgdG9rZW4g dGhhdCBoYXZlIHByZXZpb3VzbHkgYmVlbiBpc3N1ZWQgdG8gdGhlDQogICAgICAgcmVxdWVzdGlu ZyBjbGllbnQuICBJZiB0aGF0IGlzIG5vdCB0aGUgY2FzZSwgdGhlIENsaWVudC10by1BUyByZXF1 ZXN0DQogICAgDQogICAgbml0OiBJdCdzIG5vdCBjbGVhciB0aGF0IHdlIG5lZWQgaXQgdG8gaWRl bnRpZnkgYSBzcGVjaWZpYyB0b2tlbiwganVzdCBhDQogICAga2V5LiAgKEFuZCBpbiBmYWN0IGZv ciBtdWx0aXBsZSBzdWNjZXNzaXZlIGFjY2Vzcy1yaWdodHMgdXBkYXRlcywgdGhlcmUNCiAgICB3 aWxsIGJlIG1vcmUgdGhhbiBvbmUgcHJldmlvdXMgdG9rZW4uKQ0KICAgIA0KRlA6IERvbmUgaW4g UFIuIFVucmVsYXRlZCwgYnV0IHdoeSB3b3VsZCB0aGUgQVMga2VlcCBtb3JlIHRoYW4gb25lIHBy ZXZpb3VzIHRva2VuPw0KDQogICAgVGhlICJraWQiICJyZXFfY25mIiBtZW1iZXIgaW4gRmlndXJl IDQncyBleGFtcGxlIGRvZXMgbm90IGluY2x1ZGUgdGhlDQogICAgYnN0ciB3cmFwcGVyIHRoYXQg ZHJhZnQtaWV0Zi1hY2UtY3d0LXByb29mLW9mLXBvc3Nlc3Npb24gc3VnZ2VzdHMgaXMNCiAgICBy ZXF1aXJlZC4NCg0KRlA6IGNvcnJlY3QsIGtpZCBpcyBtaXNzaW5nIHRoZSBic3RyIHdyYXBwZXIs IGJ1dCByZXFfY25mIHNob3VsZCBiZSBjb3JyZWN0LCBhcyBpdCBzaG91bGQgYmUgYSBtYXAgKGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFjZS1vYXV0aC1wYXJhbXMtMTEj c2VjdGlvbi0zLjEgZGVmaW5lcyBpdCBoYXZpbmcgdGhlIHNhbWUgc3RydWN0dXJlIG9mICJjbmYi IGZyb20gZHJhZnQtaWV0Zi1hY2UtY3d0LXByb29mLW9mLXBvc3Nlc3Npb24sIHdoaWNoIGluIHNl Y3Rpb24gMy40IGRlZmluZXMgaXQgYXMgYSBDQk9SIG1hcCkuDQogICAgDQogICAgU2VjdGlvbiAz LjINCiAgICANCjI0LiAgICAgICBNb3Jlb3ZlciwgdGhlIEFTIE1VU1QgcHJvdmlzaW9uIHRoZSBm b2xsb3dpbmcgZGF0YToNCiAgICANCiAgICBJdCdzIGZyZXF1ZW50bHkgdGhlIGNhc2UgaW4gSUVU RiBkb2N1bWVudHMgdGhhdCAicHJvdmlzaW9uIiBpcyBhDQogICAgZXVwaGltaXNtIGZvciAib3V0 LW9mLWJhbmQgY29uZmlndXJhdGlvbiIsIHNvIGlmIHdlIG1lYW4gImluY2x1ZGUgaW4gdGhlDQog ICAgdG9rZW4gcmVzcG9uc2UiIGl0J3MgcHJvYmFibHkgYmV0dGVyIHRvIHNheSB0aGF0IGRpcmVj dGx5Lg0KDQpGUDogT0ssIERvbmUgaW4gUFIuDQogICAgDQoyNS4gICAgICAgQWRkaXRpb25hbGx5 LCB0aGUgQVMgTUFZIHByb3Zpc2lvbiB0aGUgZm9sbG93aW5nIGRhdGEsIGluIHRoZSBzYW1lDQog ICAgICAgcmVzcG9uc2UuDQogICAgDQogICAgV2hlbiB0aGUgQVMgZG9lcyBub3QgZG8gc28sIGhv dyBhcmUgdGhlc2UgcGFyYW1ldGVycyBkZXRlcm1pbmVkPw0KICAgIA0KRlA6IENvbnRleHQgSUQg Y2FuIGJlIG9taXR0ZWQgYW5kIG5vdCB1c2VkIGluIE9TQ09SRS4gQUVBRCBhbGcsIEhLREYgYWxn LCBzYWx0IGFuZCByZXBsYXkgd2luZG93IGNhbiBiZSBvbWl0dGVkIGFuZCB0aGVuIHRoZSBkZWZh dWx0IHZhbHVlIHdvdWxkIGJlIHVzZWQgaW4gT1NDT1JFLiBUaGF0IHNob3VsZCBiZSBjbGVhciBm cm9tIHNlY3Rpb24gNC4zLCBzcGVjaWZpY2FsbHkgdGhlIHNlbnRlbmNlOg0KIiBJbg0KICAgY2Fz ZSB0aGVzZSBwYXJhbWV0ZXJzIGFyZSBvbWl0dGVkLCB0aGUgZGVmYXVsdCB2YWx1ZXMgYXJlIHVz ZWQgYXMNCiAgIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDMuMiBvZiBbSS1ELmlldGYtY29yZS1vYmpl Y3Qtc2VjdXJpdHldLiAiDQpBbnl0aGluZyBlbHNlIHdlIG5lZWQgdG8gYWRkPw0KDQoyNi4gICAg ICAgVGhlIE9TQ09SRV9TZWN1cml0eV9Db250ZXh0IGlzIGEgQ0JPUiBtYXAgb2JqZWN0LCBkZWZp bmVkIGluDQogICAgICAgU2VjdGlvbiAzLjIuMS4gIFRoZSBtYXN0ZXIgc2VjcmV0IE1VU1QgYmUg Y29tbXVuaWNhdGVkIGFzIHRoZSAnbXMnDQogICAgICAgZmllbGQgaW4gdGhlIE9TQ09SRV9TZWN1 cml0eV9Db250ZXh0IGluIHRoZSAnY25mJyBwYXJhbWV0ZXIgb2YgdGhlDQogICAgICAgYWNjZXNz IHRva2VuIHJlc3BvbnNlIGFzIGRlZmluZWQgaW4gU2VjdGlvbiAzLjIgb2YNCiAgICAgICBbSS1E LmlldGYtYWNlLW9hdXRoLXBhcmFtc10uICBUaGUgQUVBRCBhbGdvcml0aG0gTUFZIGJlIGluY2x1 ZGVkIGFzDQogICAgDQogICAgbml0OiBzL2luIHRoZSBPU0NPUkVfU2VjdXJpdHlfQ29udGV4dC9p biB0aGUgT1NDT1JFX1NlY3VyaXR5X0NvbnRleHQNCiAgICBmaWVsZC8sIEkgdGhpbms/DQoNCkZQ OiBEb25lIGluIFBSLiBZZXMgaXQgaXMuDQogICAgDQoyNy4gICAgICAgdGhlICdhbGcnIHBhcmFt ZXRlciBpbiB0aGUgT1NDT1JFX1NlY3VyaXR5X0NvbnRleHQ7IHRoZSBIS0RGDQogICAgICAgYWxn b3JpdGhtIE1BWSBiZSBpbmNsdWRlZCBhcyB0aGUgJ2hrZGYnIHBhcmFtZXRlciBvZiB0aGUNCiAg ICAgICBPU0NPUkVfU2VjdXJpdHlfQ29udGV4dCwgYSBzYWx0IE1BWSBiZSBpbmNsdWRlZCBhcyB0 aGUgJ3NhbHQnDQogICAgICAgcGFyYW1ldGVyIG9mIHRoZSBPU0NPUkVfU2VjdXJpdHlfQ29udGV4 dCwgYW5kIHRoZSByZXBsYXkgd2luZG93IHR5cGUNCiAgICAgICBhbmQgc2l6ZSBNQVkgYmUgaW5j bHVkZWQgYXMgdGhlICdycGwnIG9mIHRoZSBPU0NPUkVfU2VjdXJpdHlfQ29udGV4dCwNCiAgICAg ICBhcyBkZWZpbmVkIGluIFNlY3Rpb24gMy4yLjEuDQogICAgDQogICAgSSB0aGluayB3ZSB3YW50 IHRvIHJld29yZCBhbGwgb2YgdGhlc2UsIGFzIEkgdW5kZXJzdGFuZCB3aGF0IHdlJ3JlIGRvaW5n DQogICAgdG8gYmUgZGVmaW5pbmcgdGhlIHBhcmFtZXRlcnMgaW4gd2hpY2ggdGhlc2UgdmFsdWVz IGFyZSBjb252ZXllZCwgaWYNCiAgICB0aGV5IGFyZSBjb252ZXllZCBhdCBhbGwuICBKdXN0IHNh eWluZyAiPFg+IE1BWSBiZSBjb252ZXllZCBpbiA8WT4iIGhhcw0KICAgIHRoZSBjb25ub3RhdGlv biB0aGF0IDxYPiBtaWdodCBhbHRlcm5hdGl2ZWx5IGJlIGNvbnZleWVkIGluIHNvbWUgb3RoZXIN CiAgICA8Wj4gdGhhdCBpcyBub3QgbWVudGlvbmVkLiAgVGhlIHJlbGV2YW50IE1BWSBmb3Igb3Vy IHB1cnBvc2VzIGlzIHRoZSBvbmUNCiAgICBhYm92ZSB0aGUgbGlzdCAtLSAidGhlIEFTIE1BWSBw cm92aXNpb24gdGhlIGZvbGxvd2luZyBkYXRhIi4NCg0KRlA6IE9LLiBJIHdpbGwgcmVtb3ZlIGFs bCB0aGUgbm9ybWF0aXZlIE1BWSBhbmQgcmVwbGFjZSB0aGVtIHdpdGggbWF5LiBXb3VsZCB0aGF0 IGJlIHN1ZmZpY2llbnQ/DQogICAgDQoyOC4gICAgICAgVGhlIHNhbWUgcGFyYW1ldGVycyBNVVNU IGJlIGluY2x1ZGVkIGFzIG1ldGFkYXRhIG9mIHRoZSBhY2Nlc3MgdG9rZW4uDQogICAgICAgVGhp cyBwcm9maWxlIFJFQ09NTUVORFMgdGhlIHVzZSBvZiBDQk9SIHdlYiB0b2tlbiAoQ1dUKSBhcyBz cGVjaWZpZWQNCiAgICAgICBpbiBbUkZDODM5Ml0uICBJZiB0aGUgdG9rZW4gaXMgYSBDV1QsIHRo ZSBzYW1lDQogICAgICAgT1NDT1JFX1NlY3VyaXR5X0NvbnRleHQgc3RydWN0dXJlIGRlZmluZWQg YWJvdmUgTVVTVCBiZSBwbGFjZWQgaW4gdGhlDQogICAgICAgJ2NuZicgY2xhaW0gb2YgdGhpcyB0 b2tlbi4NCiAgICANCiAgICBuaXQ6ICJtZXRhZGF0YSBvZiB0aGUgYWNjZXNzIHRva2VuIiBzb3Vu ZHMgbGlrZSBpdCdzIHRyeWluZyB0byBiZSBhIHRlcm0NCiAgICBvZiBhcnQsIGJ1dCBpdCBpcyBu b3QgcHJlc2VudGx5IHVzZWQgYXMgc3VjaC4gIHMvbWV0YWRhdGEvYXR0cmlidXRlcy8NCiAgICB3 b3VsZCwgSUlVQywgYmUgbW9yZSBpbiBrZWVwaW5nIHdpdGggT0F1dGggMi4wIHRyYWRpdGlvbi4N Cg0KRlA6IHJlcGhyYXNlZCBpbnRvICJwYXJ0IG9mIHRoZSBhY2Nlc3MgdG9rZW4iIGluIFBSLCBp cyB0aGF0IG9rPw0KDQogICAgbm90LW5pdDogdGhlIHNlY29uZCBzZW50ZW5jZSBzZWVtcyByZWR1 bmRhbnQgd2l0aCB0aGUgc2Vjb25kIHNlbnRlbmNlIG9mDQogICAgdGhlIHByZXZpb3VzIHBhcmFn cmFwaC4NCg0KRlA6IEkgZG8gYWdyZWUgdGhlcmUgaXMgc29tZSByZWR1bmRhbmN5LiBUaGUgcHJl dmlvdXMgc2VudGVuY2XigJlzIE1VU1QgcmVmZXJyZWQgdG8gdGhlIG1hc3RlciBzZWNyZXQgYW5k IGhvdyBpdCBNVVNUIGJlIHRyYW5zcG9ydGVkICjigJhtc+KAmSBmaWVsZCBvZiDigJhPU0NPUkVf U2VjdXJpdHlfQ29udGV4dOKAmSBpbiDigJhjbmbigJkpLCB0aGlzIHNlbnRlbmNlIGlzIGFib3V0 IE9TQ09SRV9TZWN1cml0eV9Db250ZXh0IGluIOKAmGNuZuKAmS4gSSBzdWdnZXN0IHJlbW92aW5n IHRoZSBmaXJzdCBNVVNULCBhcyB0aGF0IHdpbGwgYmUgY29tcGxpYW50IHdpdGggcG9pbnQgMjcs IHJlbW92aW5nIHRoZSBub3JtYXRpdmUgTUFZcy4NCiAgICANCjI5LiAgICAgICBUaGUgQVMgTVVT VCBhbHNvIGFzc2lnbiBhbiBpZGVudGlmaWVyIHRvIHRoZSBSUyAoc2VydmVySWQpLCBNQVkNCiAg ICAgICBhc3NpZ24gYW4gaWRlbnRpZmllciB0byB0aGUgY2xpZW50IChjbGllbnRJZCksIGFuZCBN QVkgYXNzaWduIGFuDQogICAgICAgaWRlbnRpZmllciB0byB0aGUgY29udGV4dCAoY29udGV4dElk KS4gIFRoZXNlIGlkZW50aWZpZXJzIGFyZSB0aGVuDQogICAgICAgdXNlZCBhcyBTZW5kZXIgSUQs IFJlY2lwaWVudCBJRCBhbmQgSUQgQ29udGV4dCBpbiB0aGUgT1NDT1JFIGNvbnRleHQNCiAgICAg ICBhcyBkZXNjcmliZWQgaW4gc2VjdGlvbiAzLjEgb2YgW0ktRC5pZXRmLWNvcmUtb2JqZWN0LXNl Y3VyaXR5XS4gIFRoZQ0KICAgICAgIGNvdXBsZSAoY2xpZW50IGlkZW50aWZpZXIsIGNvbnRleHQg aWRlbnRpZmllcikgTVVTVCBiZSB1bmlxdWUgaW4gdGhlDQogICAgICAgc2V0IG9mIGFsbCBjbGll bnRzIG9uIGEgc2luZ2xlIFJTLiAgTW9yZW92ZXIsIHdoZW4gYXNzaWduZWQsDQogICAgICAgc2Vy dmVySWQsIGNsaWVudElkIGFuZCBjb250ZXh0SWQgTVVTVCBiZSBpbmNsdWRlZCBpbiB0aGUNCiAg ICAgICBPU0NPUkVfU2VjdXJpdHlfQ29udGV4dCwgYXMgZGVmaW5lZCBpbiBTZWN0aW9uIDMuMi4x Lg0KICAgIA0KICAgIFtBbnkgdGltZSB3ZSdyZSBhc3NpZ25pbmcgaWRlbnRpdGllcyB3ZSBoYXZl IHRvIHNheSBzb21ldGhpbmcgYWJvdXQgdGhlDQogICAgcHJpdmFjeSBwcm9wZXJ0aWVzIHRoZXJl b2YsIG9yIGEgYnVuY2ggb2YgcmV2aWV3ZXJzIHdpbGwgY29tcGxhaW4uXQ0KDQpGUDogT0suIFdo YXQgYWJvdXQgYWRkaW5nIHByaXZhY3kgY29uc2lkZXJhdGlvbnMgcG9pbnRpbmcgdG8gdGhlIHBy aXZhY3kgY29uc2lkZXJhdGlvbnMgaW4gT1NDT1JFPyBJIGZlZWwgdGhhdCBzaG91bGQgY292ZXIg aXQuDQoNCiAgICBJcyB0aGUgUmVjaXBpZW50IElEIGV4cGVjdGVkIHRvIGJlIHN0YWJsZS9wZXJz aXN0ZW50IGZvciBhIGdpdmVuIFJTIGFzIHNlZW4NCiAgICBieSBhbGwgY2xpZW50cz8NCg0KRlA6 IE5vdCBuZWNlc3NhcmlseS4NCg0KICAgIG5pdDogImFsbCBjbGllbnRzIG9uIGEgc2luZ2xlIFJT IiByZWFkcyBvZGRseSB0byBtZTsgbWF5YmUgcy9vbi9vZi8/DQoNCkZQOiBEb25lIGluIFBSLiBz L29uL2Zvcg0KDQogICAgbml0OiBJJ2Qgc3VnZ2VzdCB0byByZXBsYWNlICJjb3VwbGUiIHdpdGgg InR1cGxlIiBvciAicGFpciIuDQoNCkZQOiBEb25lIGluIFBSOiAicGFpciIuDQoNCiAgICBuaXQ6 IHNlcnZlcklkIGlzIGFsd2F5cyBhc3NpZ25lZCBieSB0aGUgQVMsIHNvIHRoZSAid2hlbiBhc3Np Z25lZCINCiAgICBkb2Vzbid0IHF1aXRlIGJpbmQgcHJvcGVybHksIGdyYW1tYXItd2lzZS4gIFdo aWxlIHRoZSBjbGllbnRJZCBpcw0KICAgICJhbHdheXMgYXNzaWduZWQiIGJ5IHRoZSB0aW1lIG9m IHRoZSBNYXN0ZXIgU2VjcmV0IGRlcml2YXRpb24sIHRoaXMgaXMNCiAgICBqdXN0IGRpc2N1c3Np bmcgdGhlIEFTIHRva2VuIHJlc3BvbnNlLCBzbyB3ZSBjYW4ndCBuZWNlc3NhcmlseSBhc3N1bWUN CiAgICBpdCdzIGFzc2lnbmVkIGhlcmUsIGF0IGxlYXN0IHdpdGggdGhlIGN1cnJlbnQgcHJvdG9j b2wgc3BlYy4NCg0KRlA6IERvbmUgaW4gUFIuIEkgYmVsaWV2ZSB0aGlzIGlzIGEgZm9ybXVsYXRp b24gcHJvYmxlbS4gWWVzIHRoZSBzZXJ2ZXJJZCBpcyBhbHdheXMgYXNzaWduZWQsIHNvIGl0IHdv dWxkIGFsd2F5cyBiZSBpbmNsdWRlZCBpbiB0aGUgT1NDT1JFX1NlY3VyaXR5X0NvbnRleHQuIFRo ZSBwb2ludCBvZiB0aGlzIHNlbnRlbmNlIHdhczogd2hlbmV2ZXIgdGhlIEFTIGFzc2lnbnMgYSB2 YWx1ZSBmb3IgdGhlIGlkZW50aWZpZXIsIGl0IGFsc28gc2V0cyB0aGUgY29ycmVzcG9uZGluZyBm aWVsZCB0byB0aGF0IHZhbHVlIGluIHRoZSBPU0NPUkVfU2VjdXJpdHlfQ29udGV4dC4gSSByZWZv cm11bGF0ZWQ6IFRoZSBwYWlyIChjbGllbnQgaWRlbnRpZmllciwgY29udGV4dCBpZGVudGlmaWVy KSBNVVNUIGJlIHVuaXF1ZSBpbiB0aGUgc2V0IG9mIGFsbCBjbGllbnRzIGZvciBhIHNpbmdsZSBS Uy4gIE1vcmVvdmVyLCBjbGllbnRJZCwgc2VydmVySWQgYW5kICh3aGVuIGFzc2lnbmVkKSBjb250 ZXh0SWQgTVVTVCBiZSBpbmNsdWRlZCBpbiB0aGUgT1NDT1JFX1NlY3VyaXR5X0NvbnRleHQsIGFz IGRlZmluZWQgaW4gLi4uIFRoaXMgd291bGQgYmUgY29uc2lzdGVudCB3aXRoIHJlbW92aW5nIHRo ZSBvcHRpb24gb2YgY2xpZW50SWQgbm90IGJlaW5nIGluY2x1ZGVkIGluIHRoZSBPU0NPUkVfU2Vj dXJpdHlfQ29udGV4dC4NCiAgICANCiAgICBPU0NPUkUgcmVxdWlyZXMgYSBTZW5kZXIgSUQgYW5k IFJlY2lwaWVudCBJRCwgYnV0IHdlIG9ubHkgaGF2ZSBpdCBhcw0KICAgIG9wdGlvbmFsIGZvciB0 aGUgQVMgdG8gYXNzaWduIHRoZSBjbGllbnRJZCAtLSB3aGF0IGRvZXMgT1NDT1JFIHVzZSBhcw0K ICAgIHRoZSBTZW5kZXIvUmVjaXBpZW50IElEIHdoZW4gdGhlIEFTIGRvZXMgbm90IGFzc2lnbiBh IGNsaWVudElkPw0KDQpGUDogVGhhdCB3YXMgdGhlIGNhc2Ugd2hlcmUgdGhlIFJTIE1VU1QgYXNz aWduIGEgY2xpZW50SWQsIHNlZSBzZWN0aW9uIDQuMjoNCuKAnE1vcmVvdmVyLCBpZiB0aGUgT1ND T1JFX1NlY3VyaXR5X0NvbnRleHQgaW4gdGhlIHRva2VuIGRpZCBub3QNCiAgIGNvbnRhaW4gYSAn Y2xpZW50SWQnIHBhcmFtZXRlciwgdGhlIFJTIE1VU1QgZ2VuZXJhdGUgYW4gaWRlbnRpZmllciwN CiAgIHVuaXF1ZSBpbiB0aGUgc2V0IG9mIGFsbCBpdHMgZXhpc3RpbmcgY2xpZW50IGlkZW50aWZp ZXJzLCBhbmQgc2VuZCBpdA0KICAgaW4gYSAnY2xpZW50SWQnIHBhcmFtZXRlciBpbiB0aGUgQ0JP UiBtYXAgYXMgYSBDQk9SIGJzdHIu4oCcDQpCdXQgaWYgd2UgYWdyZWUgb24gcmVtb3ZpbmcgdGhp cyBtZWNoYW5pc20sIHRoaXMgYmVjb21lcyBvdXRkYXRlZC4NCiAgICANCiAgICBXaGVuIGNlcnRh aW4gZmllbGRzIGFyZSBvcHRpb25hbCwgd2UgdHlwaWNhbGx5IGhhdmUgdG8gYXNrIHdoZXRoZXIg aXQncw0KICAgIHBvc3NpYmxlIGZvciB0aGUgdHdvIHBhcnRpZXMgdG8gZGlzYWdyZWUgYWJvdXQg d2hldGhlciB0aGUgZmllbGQgaXMNCiAgICBwcmVzZW50LiAgSUlVQywgdGhlIE9TQ09SRSBjb250 ZXh0IGRlcml2YXRpb24gcHJvY2VkdXJlIGluY2x1ZGVzIGVub3VnaA0KICAgIGluZm9ybWF0aW9u IHRvIHByZXZlbnQgdGhhdCBwb3NzaWJpbGl0eSwgYnV0IGl0IHdvdWxkIGJlIGdvb2QgaWYgc29t ZW9uZQ0KICAgIHdvdWxkIGNvbmZpcm0gdGhhdC4NCg0KRlA6IFRoYXQgaXMgY29ycmVjdCwgYSBu dW1iZXIgb2YgZmllbGRzIGhhdmUgZGVmYXVsdCB2YWx1ZXMgd2hlbiBub24gcHJlc2VudC4gSGtk ZiwgYWxnLCBzYWx0LCBjb250ZXh0SWQsIHJwbC4gT24gdGhlIG90aGVyIGhhbmQsIG1zLCBjbGll bnRJZCBhbmQgc2VydmVySWQgbmVlZCB0byBiZSBzZXQuDQogICAgDQozMC4gICAgICAgV2UgYXNz dW1lIGluIHRoaXMgZG9jdW1lbnQgdGhhdCBhIHJlc291cmNlIGlzIGFzc29jaWF0ZWQgdG8gb25l DQogICAgICAgc2luZ2xlIEFTLCB3aGljaCBtYWtlcyBpdCBwb3NzaWJsZSB0byBhc3N1bWUgdW5p cXVlIGlkZW50aWZpZXJzIGZvcg0KICAgICAgIGVhY2ggY2xpZW50IHJlcXVlc3RpbmcgYSBwYXJ0 aWN1bGFyIHJlc291cmNlIHRvIGEgUlMuICBJZiB0aGlzIGlzIG5vdA0KICAgIA0KICAgIEkgZmVl bCBsaWtlIHRoaXMgbWlnaHQgYmUgbW9yZSBjbGVhciBpZiB3ZSBjYW4gZnJhbWUgaXQgaW4gdGVy bXMgb2YgdGhlDQogICAgQVMgZW5mb3JjaW5nIHRoZSB1bmlxdWVuZXNzIG9mIGNsaWVudCBpZGVu dGlmaWVycyAob3IsIGlmIHlvdSB3aWxsLCB0aGF0DQogICAgd2UgZGVsZWdhdGUgdGhlIGVuZm9y Y2VtZW50IHRoZXJlb2YgdG8gdGhlIEFTLi4uKQ0KICAgIA0KRlA6IE9LDQoNCjMxLiAgICAgICB0 aGUgY2FzZSwgY29sbGlzaW9ucyBvZiBpZGVudGlmaWVycyBtYXkgYXBwZWFyIGluIHRoZSBSUywg aW4gd2hpY2gNCiAgICAgICBjYXNlIHRoZSBSUyBuZWVkcyB0byBoYXZlIGEgbWVjaGFuaXNtIGlu IHBsYWNlIHRvIGRpc2FtYmlndWF0ZQ0KICAgICAgIGlkZW50aWZpZXJzIG9yIG1pdGlnYXRlIHRo ZWlyIGVmZmVjdC4NCiAgICANCiAgICBuaXQ6IHMvYXBwZWFyIGluL29jY3VyIGF0Lw0KDQpGUDog RG9uZSBpbiBQUi4NCg0KICAgIG5pdDogcy9taXRpZ2F0ZSB0aGVpciBlZmZlY3QvbWl0aWdhdGUg dGhlIGVmZmVjdCBvZiB0aGUgY29sbGlzaW9ucy8NCg0KRlA6IERvbmUgaW4gUFIuDQogICAgDQoz Mi4gICAgICAgTm90ZSB0aGF0IGluIFNlY3Rpb24gNC4zIEMgc2V0cyB0aGUgU2VuZGVyIElEIG9m IGl0cyBTZWN1cml0eSBDb250ZXh0DQogICAgICAgdG8gdGhlIGNsaWVudElkIHZhbHVlIHJlY2Vp dmVkIGFuZCB0aGUgUmVjaXBpZW50IElEIHRvIHRoZSBzZXJ2ZXJJZA0KICAgICAgIHZhbHVlLCBh bmQgUlMgZG9lcyB0aGUgb3Bwb3NpdGUuDQogICAgDQogICAgKFRoZSB3YXkgdGhpcyBpcyB3cml0 dGVuIGltcGxpY2l0bHkgYXNzdW1lcyB0aGF0IGJvdGggY2xpZW50SWQgYW5kDQogICAgc2VydmVy SWQgYXJlIHJlY2VpdmVkIGZyb20gdGhlIEFTLikNCg0KRlA6IFRoYXQncyByaWdodC4gSSB3b3Vs ZCBrZWVwIGFzIGlzIGlmIHdlIGFncmVlIG9uIHJlbW92aW5nIHRoZSBSUy1hc3NpZ25zLWlkZW50 aWZpZXIgbWVjaGFuaXNtLg0KICAgIA0KMzMuICAgICAgIEZpZ3VyZSA1IHNob3dzIGFuIGV4YW1w bGUgb2Ygc3VjaCBhbiBBUyByZXNwb25zZSwgaW4gQ0JPUiBkaWFnbm9zdGljDQogICAgICAgbm90 YXRpb24gd2l0aG91dCB0aGUgdGFnIGFuZCB2YWx1ZSBhYmJyZXZpYXRpb25zLg0KICAgIA0KICAg IEknZCBzdWdnZXN0IHMvc3VjaCBhbiBBUyByZXNwb25zZS9hbiBBUyB0b2tlbiByZXNwb25zZS8N Cg0KRlA6IE9LDQogICAgDQozNC4gICAgICAgICAgICAgImFjY2Vzc190b2tlbiIgOiBoJ2E1MDM3 Njc0NjU2ZDcwNTM2NTZlNzMgLi4uJw0KICAgICAgICAgICAgICAocmVtYWluZGVyIG9mIGFjY2Vz cyB0b2tlbiBvbWl0dGVkIGZvciBicmV2aXR5KScsDQogICAgDQogICAgSW4gYWRkaXRpb24gdG8g dGhlIGludmFsaWQtQ0JPUi1kaWFnbm9zdGljLW5vdGF0aW9uLXN5bnRheCBjb21tZW50LCB3ZQ0K ICAgIGFsc28gaGF2ZSB1bmJhbGFuY2VkIHF1b3Rlcy4NCg0KRlA6IFJpZ2h0LCBidXQgdGhpcyBp cyBub3QgdmFsaWQgQ0JPUiBkaWFnbm9zdGljIG5vdGF0aW9uIHN5bnRheCBhbnl3YXksIGRvIHlv dSBoYXZlIGEgYmV0dGVyIGlkZWE/IEkgZG8gbm90IHRoaW5rIGl0IHdvdWxkIGJlIHVzZWZ1bCB0 byBoYXZlIHRoZSBmdWxsIHRva2VuIGhlcmUuIFdpbGwgcmVtb3ZlIHRoZSB1bmJhbGFuY2VkIHF1 b3RlLg0KICAgIA0KMzUuICAgICAgICAgICAgICJwcm9maWxlIiA6ICJjb2FwX29zY29yZSIsDQog ICAgICAgICAgICAgImV4cGlyZXNfaW4iIDogIjM2MDAiLA0KICAgICAgICAgICAgICJjbmYiIDog ew0KICAgICAgICAgICAgICAgIk9TQ09SRV9TZWN1cml0eV9Db250ZXh0IiA6IHsNCiAgICAgICAg ICAgICAgICAgImFsZyIgOiAiQUVTLUNDTS0xNi02NC0xMjgiLA0KICAgICAgICAgICAgICAgICAi Y2xpZW50SWQiIDogYjY0J3FBJywNCiAgICAgICAgICAgICAgICAgInNlcnZlcklkIiA6IGI2NCdR ZycsDQogICAgDQogICAgQW55IHJlYXNvbiB0byBwcmVmZXIgYjY0J3FBJyBvdmVyIGgnYTgnIHdo aWNoIGlzIHNob3J0ZXI/DQoNCkZQOiBObywgdGhpcyBpcyBhIGxlZnRvdmVyIG9mIHNvbWUgcHJl dmlvdXMgZXhhbXBsZS4gV2lsbCByZW1vdmUgYjY0IGVuY29kaW5ncy4NCiAgICANCjM2LiAgICAg ICBJZiB0aGUgY2xpZW50IGhhcyByZXF1ZXN0ZWQgYW4gdXBkYXRlIHRvIGl0cyBhY2Nlc3Mgcmln aHRzIHVzaW5nIHRoZQ0KICAgICAgIHNhbWUgT1NDT1JFIFNlY3VyaXR5IENvbnRleHQsIHdoaWNo IGlzIHZhbGlkIGFuZCBhdXRob3JpemVkLCB0aGUgQVMNCiAgICAgICBNVVNUIG9taXQgdGhlICdj bmYnIHBhcmFtZXRlciBpbiB0aGUgcmVzcG9uc2UsIGFuZCBNVVNUIGNhcnJ5IHRoZQ0KICAgICAg IGNsaWVudCBpZGVudGlmaWVyIGFuZCBvcHRpb25hbGx5IHRoZSBjb250ZXh0IGlkZW50aWZpZXIg aW4gdGhlICdraWQnDQogICAgICAgZmllbGQgaW4gdGhlICdjbmYnIHBhcmFtZXRlciBvZiB0aGUg dG9rZW4sIHdpdGggdGhlIHNhbWUgc3RydWN0dXJlDQogICAgDQogICAgSSB0aGluayB3ZSBzaG91 bGQgYmUgY2FyZWZ1bCBhYm91dCByZWZlcnJpbmcgdG8gdGhpcyBhcyAib3B0aW9uYWxseSB0aGUN CiAgICBjb250ZXh0IGlkZW50aWZpZXIiIC0tIHRoZSBjaG9pY2UgZm9yIHdoZXRoZXIgdGhlcmUg aXMgYSBjb250ZXh0DQogICAgaWRlbnRpZmllciBpcyBtYWRlIG9uY2UgKGF0IGluaXRpYWwgaXNz dWFuY2UpLCBhbmQgc3Vic2VxdWVudCB1c2FnZQ0KICAgIGRlcGVuZHMgb24gd2hldGhlciBvbmUg aGFzIGJlZW4gYWxsb2NhdGVkIG9yIG5vdC4gIEl0J3Mgbm90IGxpa2UgdGhlIEFTDQogICAgY2Fu IGRlY2lkZSBhdCBydW50aW1lICJJIGdhdmUgeW91IGEgY29udGV4dCBpZGVudGlmaWVyIGZvciB5 b3VyIG9yaWdpbmFsDQogICAgc2VjdXJpdHkgY29udGV4dCwgYnV0IEkgZG9uJ3QgZmVlbCBsaWtl IGdpdmluZyBpdCB0byB5b3UgYWdhaW4iIC0tIHRoZQ0KICAgIGRlcml2ZWQga2V5cyB3b24ndCBt YXRjaCB1cCBhbmQgaXQgd29uJ3QgYmUgcmV1c2FibGUgYXMgdGhlIHNhbWUNCiAgICBzZWN1cml0 eSBjb250ZXh0Lg0KDQpGUDogUmlnaHQsIHRoaXMgYWdhaW4gaXMgYSBmb3JtdWxhdGlvbiBwcm9i bGVtLiBUaGUgb3B0aW9uYWxpdHkgY29tZXMgZnJvbSBpZiBpdCBoYXMgZXZlciBiZWVuIGFzc2ln bmVkL2FsbG9jYXRlZC9zZXQgZm9yIHRoYXQgc2VjdXJpdHkgY29udGV4dC4gV2hhdCBhYm91dCBy ZWZvcm11bGF0aW5nIGludG86IA0KLCBhbmQgTVVTVCBjYXJyeSB0aGUNCiAgICAgICBjbGllbnQg aWRlbnRpZmllciBhbmQgdGhlIGNvbnRleHQgaWRlbnRpZmllciAoaWYgaXQgd2FzIHNldCBhbmQg aW5jbHVkZWQgaW4gdGhlIGluaXRpYWwgYWNjZXNzIHRva2VuIHJlc3BvbnNlIGJ5dCB0aGUgQVMp IGluIHRoZSAna2lkJw0KICAgICAgIGZpZWxkIGluIHRoZSAnY25mJyBwYXJhbWV0ZXIgb2YgdGhl IHRva2VuLCB3aXRoIHRoZSBzYW1lIHN0cnVjdHVyZQ0KDQogICAgQWxzbywgSSdtIG5vdCBzdXJl IHRoaXMgaXMgZnVsbHkgZGVmaW5lZCBmb3IgdGhlIGNhc2Ugd2hlbiB0aGUgUlMNCiAgICBvdmVy cmlkZXMgdGhlIEFTJ3MgY2xpZW50SWQgYXNzaWdubWVudCwgYXMgdGhlIGtpZCBhcnJheSBpbiB0 aGUgdG9rZW4NCiAgICBuZWVkcyB0byBiZSB0aGUgdmFsdWUgdGhlIFJTIHdpbGwga25vdywgYnV0 IHRoZSBraWQgaW4gcmVxX2NuZiBuZWVkcyB0bw0KICAgIGJlIHRoZSBvbmUgdGhlIEFTIGtub3dz LCBhbmQgd2UgZG9uJ3QgcmVhbGx5IGRlZmluZSBhIG1lY2hhbmlzbSBmb3IgdGhlDQogICAgQVMg dG8gYmUgYWJsZSB0byBkbyB0cmFuc2xhdGlvbiBmcm9tIG9uZSB0byB0aGUgb3RoZXIuDQogICAg DQpGUDogUmlnaHTigKYgdGhpcyBpcyBnZXR0aW5nIGNvbXBsaWNhdGVkLiBJZiB0aGUgY2xpZW50 IGFuZCB0aGUgUlMgYm90aCBrZXB0IHRyYWNrIG9mIEFTLWFzc2lnbmVkIGFuZCBSUy1hc3NpZ25l ZCBjbGllbnRJZCwgdGhhdCBjb3VsZCBzdGlsbCB3b3JrLiBPciBpZiB0aGVyZSB3YXMgYSBtZWNo YW5pc20gZm9yIHRoZSBjbGllbnQgdG8gY29tbXVuaWNhdGUgdG8gdGhlIEFTOiDigJx0aGlzIGlz IHRoZSBSUy1hc3NpZ25lZCBraWQsIHRoaXMgaXMgdGhlIEFTLWFzc2lnbmVkIGtpZCwgcGxlYXNl IHRhbGsgdG8gbWUgYXMgdGhlIGZvcm1lcuKAnS4gQXMgbWVudGlvbmVkLCBJIHRoaW5rIHRoaXMg aXMgZ2V0dGluZyB0b28gY29tcGxpY2F0ZWQgYW5kIHByb3Bvc2UgcmVtb3ZpbmcgdGhpcyBtZWNo YW5pc20gYWx0b2dldGhlci4NCg0KMzcuICAgICAgIGRlZmluZWQgaW4gRmlndXJlIDMuICBUaGVz ZSBpZGVudGlmaWVycyBuZWVkIHRvIGJlIHByb3Zpc2lvbmVkLCBpbg0KICAgICAgIG9yZGVyIGZv ciB0aGUgUlMgdG8gaWRlbnRpZnkgdGhlIHByZXZpb3VzbHkgZ2VuZXJhdGVkIFNlY3VyaXR5DQog ICAgICAgQ29udGV4dC4NCiAgICANCiAgICBuaXRzOiB0aGVyZSdzIG9ubHkgb25lIChub3QgInRo ZXNlIikgaWRlbnRpZmllciBpbiB0aGUgdG9rZW4sIGFuZA0KICAgIG5vdGhpbmcgaW4gdGhlIHRv a2VuIHJlc3BvbnNlOyBhbmQgYSBzaW1pbGFyIHJlbWFyayBhYm91dCAicHJvdmlzaW9uZWQiDQog ICAgYXMgd2FzIG1hZGUgYWJvdmUuDQoNCkZQOiBIZXJlIGl0IHJlZmVycmVkIHRvIGJvdGggY2xp ZW50SWQgYW5kIGNvbnRleHRJZCAoZnJvbSB0aGUgcHJldmlvdXMgc2VudGVuY2UpLCB3aGljaCBh cmUgY2FycmllZCBpbiB0aGUga2lkIGZpZWxkLCBzbyBJIHRoaW5rIOKAnHRoZXNl4oCdIHNob3Vs ZCBiZSBvay4gUGxlYXNlIGNvcnJlY3QgbWUgaWYgSSBhbSB3cm9uZy4gT2sgYWJvdXQgcHJvdmlz aW9uZWQsIGRvbmUgaW4gUFIuDQogICAgDQozOC4gICAgICAgRmlndXJlIDkgc2hvd3MgYW4gZXhh bXBsZSBDV1QsIGNvbnRhaW5pbmcgdGhlIG5lY2Vzc2FyeSBPU0NPUkUNCiAgICAgICBwYXJhbWV0 ZXJzIGluIHRoZSAnY25mJyBjbGFpbSBmb3IgdXBkYXRlIG9mIGFjY2VzcyByaWdodHMsIGluIENC T1INCiAgICAgICBkaWFnbm9zdGljIG5vdGF0aW9uIHdpdGhvdXQgdGFnIGFuZCB2YWx1ZSBhYmJy ZXZpYXRpb25zLg0KICAgIA0KICAgICAgICAgew0KICAgICAgICAgICAiYXVkIiA6ICJ0ZW1wU2Vu c29ySW5MaXZpbmdSb29tIiwNCiAgICAgICAgICAgImlhdCIgOiAiMTM2MDE4OTIyNCIsDQogICAg ICAgICAgICJleHAiIDogIjEzNjAyODkyMjQiLA0KICAgICAgICAgICAic2NvcGUiIDogICJ0ZW1w ZXJhdHVyZV9oIiwNCiAgICAgICAgICAgImNuZiIgOiB7DQogICAgICAgICAgICAgImtpZCIgOiBi NjQncUEnDQogICAgDQogICAgSSBkb24ndCB0aGluayB0aGlzICJraWQiIGlzIGEgdmFsaWQgQ0JP UiBic3RyIHdyYXBwaW5nIHRoZSBvbmUtIG9yDQogICAgdHdvLWVsZW1lbnQgYXJyYXkuDQoNCkZQ OiBPSw0KICAgIA0KICAgIFNlY3Rpb24gMy4yLjENCiAgICANCjM5LiAgICAgICBbSS1ELmlldGYt Y29yZS1vYmplY3Qtc2VjdXJpdHldKS4gIFRoZSBPU0NPUkVfU2VjdXJpdHlfQ29udGV4dCBvYmpl Y3QNCiAgICAgICBjYW4gZWl0aGVyIGJlIGVuY29kZWQgYXMgSlNPTiBvYmplY3Qgb3IgYXMgQ0JP UiBtYXAuICBJbiBib3RoIGNhc2VzLA0KICAgIA0KICAgIG5pdHMgImEgSlNPTiBvYmplY3QiLCAi YSBDQk9SIG1hcCIuDQoNCkZQOiBEb25lIGluIFBSLg0KICAgIA0KNDAuICAgICAgIGRlZmluZWQg YmVsb3cuICBBbGwgcGFyYW1ldGVycyBhcmUgb3B0aW9uYWwuICBUYWJsZSAxIHByb3ZpZGVzIGEN CiAgICAgICBzdW1tYXJ5IG9mIHRoZSBPU0NPUkVfU2VjdXJpdHlfQ29udGV4dCBwYXJhbWV0ZXJz IGRlZmluZWQgaW4gdGhpcw0KICAgICAgIHNlY3Rpb24uDQogICAgDQogICAgVGhleSdyZSBvcHRp b25hbCB0byBhcHBlYXIgaW4gdGhlIE9TQ09SRV9TZWN1cml0eV9Db250ZXh0IG9iamVjdCB0aGF0 J3MNCiAgICBpbmNsdWRlZCBpbiBhICJjbmYiIHZhbHVlLCBidXQgbm90IG5lY2Vzc2FyaWx5IG9w dGlvbmFsIGZvciBPU0NPUkUgdG8gYmUNCiAgICB1c2FibGUuICBXaGF0IGRvIHdlIGRvIGZvciBP U0NPUkUgd2hlbiBhbnkgZ2l2ZW4gcGFyYW1ldGVyIGlzIG5vdA0KICAgIHByZXNlbnQgaW4gdGhp cyBzdHJ1Y3R1cmU/ICAoQWxzbywgZG9lc24ndCB0aGUgQVMgYWx3YXlzIGhhdmUgdG8gcHJvdmlk ZQ0KICAgIHRoaW5ncyBsaWtlICdtcycgYW5kICdzZXJ2ZXJJZCc/KQ0KDQpGUDogVGhpcyBpcyBq dXN0IHRoZSBzdHJ1Y3R1cmUgZGVmaW5pdGlvbiwgd2hpY2ggaXMgYWltZWQgdG8gYmUgbW9yZSBn ZW5lcmFsIHRoYW4ganVzdCBmb3IgdGhpcyBzcGVjLiBGb3IgZXhhbXBsZSwgdGhpcyBjb3VsZCBi ZSByZXVzZWQgdG8gc2VuZCBvbmx5IGEgcGFydCBvZiB0aGVzZSBwYXJhbWV0ZXJzLCBmb3IgZXhh bXBsZSBpZiBvbmx5IHRoZSBzYWx0ICsgaWRlbnRpZmllcnMgbmVlZCB0byBiZSB1cGRhdGVkLiBZ ZXMsIHRoYXQgaXMgY29ycmVjdCwgbm90IGFsbCBwYXJhbWV0ZXJzIGFyZSBvcHRpb25hbCB3aGVu IHVzZWQgaW4gdGhpcyBwcm9maWxlLCBhcyBtZW50aW9uZWQgaW4gYSBwcmV2aW91cyBwb2ludC4g bXMsIHNlcnZlcklkIGFyZSBub3Qgb3B0aW9uYWwuIEluIGFuIE9TQ09SRSBTZWN1cml0eSBDb250 ZXh0OiBtYXN0ZXIgc2VjcmV0LCBzZW5kZXIgSWQgYW5kIHJlY2lwaWVudCBJZCBhcmUgbm90IG9w dGlvbmFsLiBTZWN0aW9uIDQuMyBkZXNjcmliZXMgd2hhdCBoYXBwZW5zIGlmIGFueSBvZiB0aGUg cGFyYW1ldGVycyBpcyBub3QgcHJlc2VudDoNCuKAnElmIGFueSBvZiB0aGUgZXhwZWN0ZWQgcGFy YW1ldGVycyBpcyBtaXNzaW5nIChlLmcuIGFueSBvZiB0aGUNCiAgIG1hbmRhdG9yeSBwYXJhbWV0 ZXJzIGZyb20gdGhlIEFTLCBvciB0aGUgJ2NsaWVudElkJywgZWl0aGVyIHJlY2VpdmVkDQogICBm cm9tIHRoZSBBUyBvciBpbiB0aGUgMi4wMSAoQ3JlYXRlZCkgcmVzcG9uc2UgZnJvbSB0aGUgUlMp LCB0aGUNCiAgIGNsaWVudCBNVVNUIHN0b3AgdGhlIGV4Y2hhbmdlLCBhbmQgTVVTVCBOT1QgZGVy aXZlIHRoZSBTZWN1cml0eQ0KICAgQ29udGV4dC4gIFRoZSBjbGllbnQgTUFZIHJlc3RhcnQgdGhl IGV4Y2hhbmdlLCB0byBnZXQgdGhlIGNvcnJlY3QNCiAgIHNlY3VyaXR5IG1hdGVyaWFsLuKAnQ0K ICAgIA0KNDEuICAgICAgIHwgaGtkZiAgICAgIHwgNCAgICAgfCBic3RyIC8gaW50ICAgICB8IENP U0UgICAgICAgICB8IE9TQ09SRSBIS0RGICAgfA0KICAgICAgIHwgICAgICAgICAgIHwgICAgICAg fCAgICAgICAgICAgICAgICB8IEFsZ29yaXRobSAgICB8IHZhbHVlICAgICAgICAgfA0KICAgICAg IHwgICAgICAgICAgIHwgICAgICAgfCAgICAgICAgICAgICAgICB8IFZhbHVlcyAgICAgICB8ICAg ICAgICAgICAgICAgfA0KICAgICAgIHwgICAgICAgICAgIHwgICAgICAgfCAgICAgICAgICAgICAg ICB8IChITUFDLWJhc2VkKSB8ICAgICAgICAgICAgICAgfA0KICAgIA0KICAgIFNob3VsZCBiZSB0 c3RyLCBub3QgYnN0ciwgcmlnaHQ/DQoNCkZQOiBZZXMsIE9LLg0KICAgIA0KICAgIEFsc28sIHdo eSBkbyB3ZSBuZWVkIHRoZSBzdHJpbmcgZm9ybSBvZiBlaXRoZXIgaGtkZiBvciBhbGc/ICBNb3Jl DQogICAgcG9zc2liaWxpdGllcyBtYWtlcyB0aGUgZGVjb2RlciBtb3JlIGNvbXBsaWNhdGVkIGFu ZCBpbmNyZWFzZXMgdGhlDQogICAgYXR0YWNrIHN1cmZhY2UuDQoNCkZQOiBiZWNhdXNlIGEgQ09T RSBhbGdvcml0aG0gY2FuIGJlIHJlZ2lzdGVyZWQgYXMgYSBzdHJpbmcgKHNlZSBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjODE1MiNzZWN0aW9uLTE2LjQg4oCcVmFsdWXigJ0pLg0KICAg IA0KNDIuICAgICAgIHwgcnBsICAgICAgIHwgOCAgICAgfCBic3RyIC8gaW50ICAgICB8ICAgICAg ICAgICAgICB8IE9TQ09SRSBSZXBsYXkgfA0KICAgICAgIHwgICAgICAgICAgIHwgICAgICAgfCAg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8IFdpbmRvdyBUeXBlICAgfA0KICAgICAgIHwg ICAgICAgICAgIHwgICAgICAgfCAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8IGFuZCBT aXplICAgICAgfA0KICAgIA0KICAgIFNob3VsZCBqdXN0IGJlIGJzdHIgKG5vdCBpbnQpLCByaWdo dD8NCiAgICANCkZQOiBZZXMuIE9LLg0KDQo0My4gICAgICAgaGtkZjogIFRoaXMgcGFyYW1ldGVy IGlkZW50aWZpZXMgdGhlIE9TQ09SRSBIS0RGIEFsZ29yaXRobS4gIEZvciBtb3JlDQogICAgICAg ICAgaW5mb3JtYXRpb24gYWJvdXQgdGhpcyBmaWVsZCwgc2VlIHNlY3Rpb24gMy4xIG9mDQogICAg ICAgICAgW0ktRC5pZXRmLWNvcmUtb2JqZWN0LXNlY3VyaXR5XS4gIFRoZSB2YWx1ZXMgdXNlZCBN VVNUIGJlDQogICAgICAgICAgcmVnaXN0ZXJlZCBpbiB0aGUgSUFOQSAiQ09TRSBBbGdvcml0aG1z IiByZWdpc3RyeSBhbmQgTVVTVCBiZQ0KICAgICAgICAgIEhNQUMtYmFzZWQgSEtERiBhbGdvcml0 aG1zLiAgVGhlIHZhbHVlIGNhbiBlaXRoZXIgYmUgdGhlIGludGVnZXINCiAgICANCiAgICBJdCdz IGEgbGl0dGxlIHVuZm9ydHVuYXRlIHRoYXQgd2UgYmFzaWNhbGx5IGFyZSByZWx5aW5nIG9uICJJ IGtub3cgaXQNCiAgICB3aGVuIEkgc2VlIGl0IiBmb3IgZGV0ZXJtaW5pbmcgd2hpY2ggYWxnb3Jp dGhtcyBhcmUgSEtERiBhbGdvcml0aG1zLg0KDQpGUDogQWdyZWVkLCBidXQgd2UgZG9u4oCZdCBy ZWFsbHkgaGF2ZSBhbm90aGVyIHdheSB0byBzYXkgdGhpcy4gSWYgeW91IG9yIENPU0UgZXhwZXJ0 cyAoSmltKSBoYXZlIGFueSBpZGVhIHBsZWFzZSBsZXQgdXMga25vdy4gICAgDQoNCiAgICBBbHNv LCAiSEtERiIgZXhwYW5kcyB0byAiSE1BQy1iYXNlZCBFeHRyYWN0LWFuZC1FeHBhbmQgS2V5IERl cml2YXRpb24NCiAgICBGdW5jdGlvbiIsIGkuZS4sIGlzIGRlZmluaXRpb25hbGx5IEhNQUMtYmFz ZWQuICBTbyB0aGlzIHNob3VsZCBiZQ0KICAgIHJld29yZGVkIHRvIHJlZmxlY3QgdGhlIGFjdHVh bCBpbnRlbnQuDQoNCkZQOiBSaWdodCwgdGhhdCBpcyBiZWNhdXNlIENPU0UgYWxzbyBkZWZpbmVz IEhLREYgdXNpbmcgQUVTLU1BQywgc2VlIFRhYmxlIDEyIG9mIFJGQzgxNTIsIHNvIHdlIG5lZWRl ZCB0byBzcGVjaWZ5IHRoYXQgb25seSBITUFDLWJhc2VkIGNhbiBiZSB1c2VkLg0KICAgIA0KNDQu ICAgICAgIGFsZzogIFRoaXMgcGFyYW1ldGVyIGlkZW50aWZpZXMgdGhlIE9TQ09SRSBBRUFEIEFs Z29yaXRobS4gIEZvciBtb3JlDQogICAgICAgICAgaW5mb3JtYXRpb24gYWJvdXQgdGhpcyBmaWVs ZCwgc2VlIHNlY3Rpb24gMy4xIG9mDQogICAgICAgICAgW0ktRC5pZXRmLWNvcmUtb2JqZWN0LXNl Y3VyaXR5XSBUaGUgdmFsdWVzIHVzZWQgTVVTVCBiZSByZWdpc3RlcmVkDQogICAgICAgICAgaW4g dGhlIElBTkEgIkNPU0UgQWxnb3JpdGhtcyIgcmVnaXN0cnkgYW5kIE1VU1QgYmUgQUVBRA0KICAg ICAgICAgIGFsZ29yaXRobXMuICBUaGUgdmFsdWUgY2FuIGVpdGhlciBiZSB0aGUgaW50ZWdlciBv ciB0aGUgdGV4dA0KICAgIA0KICAgIFNpbWlsYXJseSwgdGhpcyBzZWVtcyB0byBiZSAiSSBrbm93 IGl0IHdoZW4gSSBzZWUgaXQiLg0KICAgIA0KRlA6IFllcy4NCg0KNDUuICAgICAgIGNvbnRleHRJ ZDogIFRoaXMgcGFyYW1ldGVyIGlkZW50aWZpZXMgdGhlIHNlY3VyaXR5IGNvbnRleHQgYXMgYSBi eXRlDQogICAgICAgICAgc3RyaW5nLiAgVGhpcyBpZGVudGlmaWVyIGlzIHVzZWQgYXMgT1NDT1JF IElEIENvbnRleHQuICBGb3IgbW9yZQ0KICAgICAgICAgIGluZm9ybWF0aW9uIGFib3V0IHRoaXMg ZmllbGQsIHNlZSBzZWN0aW9uIDMuMSBvZg0KICAgICAgICAgIFtJLUQuaWV0Zi1jb3JlLW9iamVj dC1zZWN1cml0eV0uICBJbiBKU09OLCB0aGUgImNvbnRleHRJRCIgdmFsdWUNCiAgICAgICAgICBp cyBhIEJhc2U2NCBlbmNvZGVkIGJ5dGUgc3RyaW5nLiAgSW4gQ0JPUiwgdGhlICJjb250ZXh0SUQi IHR5cGUgaXMNCiAgICAgICAgICBic3RyLCBhbmQgaGFzIGxhYmVsIDcuDQogICAgDQogICAgRG8g d2UgbmVlZCB0byBmb3JiaWQgcHJlc2VudC1idXQtZW1wdHkgY29udGV4dElkcyBpbiBvcmRlciB0 byBhdm9pZA0KICAgIGNyeXB0b2dyYXBoaWMgY29sbGlzaW9uIHdpdGggYWJzZW50LWNvbnRleHRJ ZD8NCg0KRlA6IFRoZSBmaWVsZCBiZWluZyBwcmVzZW50IGJ1dCBlbXB0eSAoaS5lLiB2YWx1ZSBp cyB0aGUgZW1wdHkgYnl0ZSBzdHJpbmcpIGlzIG5vdCB0aGUgc2FtZSBhcyBhYnNlbnQsIGluIE9T Q09SRS4gU28gd2UgZG8gbm90IG5lZWQgdG8gZm9yYmlkIHRoYXQuDQogICAgDQo0Ni4gICAgICAg cnBsOiAgVGhpcyBwYXJhbWV0ZXIgaXMgdXNlZCB0byBjYXJyeSB0aGUgT1NDT1JFIHZhbHVlLCBl bmNvZGVkIGFzIGENCiAgICAgICAgICBic3RyLiAgVGhpcyBwYXJhbWV0ZXIgaWRlbnRpZmllcyB0 aGUgT1NDT1JFIFJlcGxheSBXaW5kb3cgU2l6ZSBhbmQNCiAgICAgICAgICBUeXBlIHZhbHVlLCB3 aGljaCBpcyBhIGJ5dGUgc3RyaW5nLiAgRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQNCiAgICAg ICAgICB0aGlzIGZpZWxkLCBzZWUgc2VjdGlvbiAzLjEgb2YgW0ktRC5pZXRmLWNvcmUtb2JqZWN0 LXNlY3VyaXR5XS4NCiAgICAgICAgICBJbiBKU09OLCB0aGUgInJwbCIgdmFsdWUgaXMgYSBCYXNl NjQgZW5jb2RlZCBieXRlIHN0cmluZy4gIEluDQogICAgICAgICAgQ0JPUiwgdGhlICJycGwiIHR5 cGUgaXMgYnN0ciwgYW5kIGhhcyBsYWJlbCA4Lg0KICAgIA0KICAgIEkgdHJpZWQgdG8gZm9sbG93 IHRoZSByZWZlcmVuY2UsIGJ1dCBJIGNvdWxkbid0IHJlYWxseSBmaW5kIGENCiAgICBkZXNjcmlw dGlvbiBvZiB0aGUgZW5jb2RpbmcgZm9yIHRoaXMgYXMgYSBieXRlIHN0cmluZyAoZXNwZWNpYWxs eQ0KICAgIG5vdGV3b3J0aHkgc2luY2Ugd2UgY2xhaW0gdGhhdCBpdCByZXByZXNlbnRzIGJvdGgg c2l6ZSBhbmQgdHlwZSkuDQogICAgKFJlbGF0ZWRseSwgSSdtIG5vdCBzdXJlIHdoeSBpdCdzIGFs bG93ZWQgdG8gYmUgZWl0aGVyIGJzdHIgb3IgaW50LikNCiAgICANCkZQOiBSaWdodCwgdGhpcyBp cyBhbiBvbGQgcmVmZXJlbmNlLCB3aGVyZSB3ZSBhY3R1YWxseSBnYXZlIGEgZGVmYXVsdCBlbmNv ZGluZyBmb3IgcnBsLCBJIGJlbGlldmUuIE5vdyB0aGlzIGlzIGVudGlyZWx5IHVwIHRvIHRoZSBh cHBsaWNhdGlvbi4gSSB3b3VsZCBrZWVwIHRoaXMgYXMgYnN0ciBhbmQgc3BlY2lmeSB0aGF0IGl0 IGlzIGFueSBmb3JtYXQgd3JhcHBlZCBpbiBhIGJzdHIuDQpBbHNvIEkgbmVlZCB0byBmaXggYSBj b3VwbGUgb2YgbWlzdGFrZXM6IOKAnE9TQ09SRSB2YWx1ZeKAnSBpcyB3cm9uZzsg4oCcUmVwbGF5 IFdpbmRvd+KAnSBhbmQgbm90ICJTaXplIGFuZCBUeXBlIi4gQWxzbywgSSB0aGluayB3ZSBuZWVk IHRvIGRlZmluZSBhIG5ldyBJQU5BIHJlZ2lzdHJ5IGZvciBycGwgd2l0aCAwIGFzIGRlZmF1bHQs IHNvIHRoYXQgYXBwbGljYXRpb25zIGNhbiBkZWZpbmUgdGhlaXIgZm9ybWF0Lg0KDQogICAgU2Vj dGlvbiA0DQogICAgDQo0Ny4gICAgQ2FuIHdlIGdldCBzb21lIENEREwgb3Igc2ltaWxhciBmb3Ig Ym90aCBDLXRvLVJTIGFuZCBSUy10by1DIChpbiB0aGUNCiAgICByZXNwZWN0aXZlIHN1YnNlY3Rp b25zKT8NCiAgICANCkZQOiBJIGFtIG5vdCBzdXJlIHdoYXQgeW914oCZZCBsaWtlIHRvIHNlZSBp biBDRERMIGluIHRoaXMgc3Vic2VjdGlvbiwgY291bGQgeW91IGV4cGFuZD8NCg0KNDguICAgIEkn ZCBuYWl2ZWx5IGV4cGVjdCBhIHNlY3Rpb24gdGl0bGVkICJDbGllbnQtUlMgQ29tbXVuaWNhdGlv biIgdG8gaW5jbHVkZQ0KICAgIHNvbWUgZGlzY3Vzc2lvbiBvZiBub3JtYWwgcHJvdGVjdGVkIE9T Q09SRSByZXF1ZXN0L3Jlc3BvbnNlIHBhaXJzIG9uY2UNCiAgICB0aGUgc2VjdXJpdHkgY29udGV4 dCBpcyBmdWxseSBlc3RhYmxpc2hlZCwgYnV0IHRoaXMgaW5pdGlhbCBzZWN0aW9uDQogICAgYmFz aWNhbGx5IG9ubHkgdGFsa3MgYWJvdXQgdGhlIGF1dGh6LWluZm8gaW50ZXJhY3Rpb24gYW5kIGRp c2NsYWltcyB0aGF0DQogICAgdGhlIHN1YnNlY3Rpb25zIHdpbGwgY292ZXIgYW55dGhpbmcgZWxz ZS4NCg0KRlA6IE9rLCB3aWxsIGFkZCBzb21lIGludHJvZHVjdG9yeSB0ZXh0IGFib3V0IHRoZSBP U0NPUkUgc2VjdXJpdHkgY29udGV4dCBiZWluZyB1c2VkIG9mIGZ1dHVyZSBPU0NPUkUgcHJvdGVj dGVkIGNvbW11bmljYXRpb24uDQogICAgDQo0OS4gICAgICAgVGhlIGZvbGxvd2luZyBzdWJzZWN0 aW9ucyBkZXNjcmliZSB0aGUgZGV0YWlscyBvZiB0aGUgUE9TVCByZXF1ZXN0DQogICAgICAgYW5k IHJlc3BvbnNlIHRvIHRoZSBhdXRoei1pbmZvIGVuZHBvaW50IGJldHdlZW4gY2xpZW50IGFuZCBS Uy4gIFRoZQ0KICAgICAgIGNsaWVudCBnZW5lcmF0ZXMgYSBub25jZSBOMSBhbmQgcG9zdHMgaXQg dG9nZXRoZXIgd2l0aCB0aGUgdG9rZW4gdGhhdA0KICAgICAgIGluY2x1ZGVzIHRoZSBtYXRlcmlh bHMgcHJvdmlzaW9uZWQgYnkgdGhlIEFTIHRvIHRoZSBSUy4gIFRoZSBSUyB0aGVuDQogICAgICAg ZGVyaXZlcyBhIG5vbmNlIE4yIGFuZCB1c2UgU2VjdGlvbiAzLjIgb2YNCiAgICANCiAgICBuaXRz OiAicHJvdmlzaW9uZWQiIGFnYWluLCBhbmQgdGhlIFJTIGlzIGdvaW5nIHRvIGJlIGdlbmVyYXRp bmcgYSBub25jZQ0KICAgIGZyb20gc2NyYXRjaCwgbm90IGRlcml2aW5nIG9uZSBmcm9tIC4uLiBh bnl0aGluZyBlbHNlLCByZWFsbHkuDQoNCkZQOiBEb25lIGluIFBSLg0KICAgIA0KNTAuICAgICAg IFtJLUQuaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eV0gdG8gZGVyaXZlIGEgc2VjdXJpdHkgY29u dGV4dCBiYXNlZCBvbg0KICAgICAgIGEgc2hhcmVkIG1hc3RlciBzZWNyZXQgYW5kIHRoZSB0d28g bm9uY2VzLCBlc3RhYmxpc2hlZCBiZXR3ZWVuIGNsaWVudA0KICAgICAgIGFuZCBzZXJ2ZXIuDQog ICAgDQogICAgKFRoZSBzaGFyZWQgbWFzdGVyIHNlY3JldCBpcyBwYXJ0IG9mIHdoYXQgdGhlIEFT IHByb3Zpc2lvbnNeV2dpdmVzIHRvDQogICAgdGhlIFJTLCByaWdodD8pDQoNCkZQOiBZZXMsIGNv cnJlY3QuIEFjdHVhbGx5IGhlcmUgaXQgaXMgYWxzbyB0aGUgY2xpZW50SWQsIHNlcnZlcklkIGFu ZCBjb250ZXh0SWQgKGlmIGFueSkgdGhhdCBhcmUgdXNlZCBmb3IgZGVyaXZpbmcgdGhlIE9TQ09S RSBjb250ZXh0Lg0KICAgIA0KNTEuICAgICAgIE5vdGUgdGhhdCB0aGUgcHJvb2Ytb2YtcG9zc2Vz c2lvbiByZXF1aXJlZCB0byBiaW5kIHRoZSBhY2Nlc3MgdG9rZW4NCiAgICAgICB0byB0aGUgY2xp ZW50IGlzIGltcGxpY2l0bHkgcGVyZm9ybWVkIGJ5IGdlbmVyYXRpbmcgdGhlIHNoYXJlZCBPU0NP UkUNCiAgICAgICBTZWN1cml0eSBDb250ZXh0IHVzaW5nIHRoZSBwb3Ata2V5IGFzIG1hc3RlciBz ZWNyZXQsIGZvciBib3RoIGNsaWVudA0KICAgICAgIGFuZCBSUy4gIEFuIGF0dGFja2VyIHVzaW5n IGEgc3RvbGVuIHRva2VuIHdpbGwgbm90IGJlIGFibGUgdG8NCiAgICAgICBnZW5lcmF0ZSBhIHZh bGlkIE9TQ09SRSBjb250ZXh0IGFuZCB0aHVzIG5vdCBiZSBhYmxlIHRvIHByb3ZlDQogICAgICAg cG9zc2Vzc2lvbiBvZiB0aGUgcG9wLWtleS4NCiAgICANCiAgICBJdCBtYXkgYmUgd29ydGggc2F5 aW5nIHNvbWV0aGluZyByb3VnaGx5IGVxdWF0aW5nICJwcm9vZiBvZiBwb3NzZXNpb24NCiAgICBw ZXJmb3JtZWQgYnkgdGhlIFJTIiBhbmQgInRoZSBSUyBhdXRoZW50aWNhdGluZyBpdHNlbGYgdG8g dGhlIGNsaWVudCIsDQogICAgc2luY2UgdGhlcmUgaXMgbm90IGFuIGV4dGVybmFsIGFjdGlvbiBm b3Igc2VydmVyIGF1dGhlbnRpY2F0aW9uLg0KICAgIEFsc28sIElTVFIgZ2V0dGluZyBzb21lIHB1 c2hiYWNrIG9uIGEgZGlmZmVyZW50IGRvY3VtZW50IHRoYXQgdGFsa2VkDQogICAgYWJvdXQgYW4g YXR0YWNrZXIgd2l0aCBhICJzdG9sZW4gdG9rZW4iLCBhcyBzb21ldGhpbmcgdGhhdCBjYW4gc3Rl YWwgYQ0KICAgIHRva2VuIGZyb20gdGhlIGNsaWVudCdzIGxvY2FsIHN0b3JhZ2UgbWlnaHQgYWxz byBzdGVhbCB0aGUgYXNzb2NpYXRlZA0KICAgIGtleS4gIEkgZm9yZ2V0IGlmIHdlIGVuZGVkIHVw IGNoYW5naW5nIHRvIHNvbWUgb3RoZXIgcGhyYXNpbmcgb3Igbm90LA0KICAgIHRob3VnaCA6KA0K DQpGUDogT2ssIHdpbGwgcmVwaHJhc2UgdG8g4oCcdGhlIFJTIGF1dGhlbnRpY2F0aW5nIGl0c2Vs ZuKAnSBpbnN0ZWFkIG9mIOKAnHBvcCBwZXJmb3JtZWQgYnkgdGhlIFJT4oCdLiBBbHNvLCB3aGF0 IGFib3V0IHVzaW5nIGVhdmVzZHJvcCBoZXJlIGluc3RlYWQ/DQogICAgDQogICAgU2VjdGlvbiA0 LjENCiAgICANCjUyLiAgICAgICBUaGUgY2xpZW50IE1VU1QgZ2VuZXJhdGUgYSBub25jZSBOMSB2 ZXJ5IHVubGlrZWx5IHRvIGhhdmUgYmVlbg0KICAgICAgIHByZXZpb3VzbHkgdXNlZCB3aXRoIHRo ZSBzYW1lIGlucHV0IGtleWluZyBtYXRlcmlhbC4gIFRoaXMgcHJvZmlsZQ0KICAgICAgIFJFQ09N TUVORFMgdG8gdXNlIGEgNjQtYml0IGxvbmcgcmFuZG9tIG51bWJlciBhcyBub25jZS4gIFRoZSBj bGllbnQNCiAgICANCiAgICBXaHkgNjQgaW5zdGVhZCBvZiAxMjg/ICBJIGtub3cgdGhhdCAxMjgg aXMgZW5vdWdoIHdpdGhvdXQgaGF2aW5nIHRvDQogICAgdGhpbmsgYWJvdXQgaXQ7IGZvciA2NCB3 ZSBoYXZlIHRvIGJlIGNsZWFyIGFib3V0IHdoYXQgcm9sZSB0aGUgbm9uY2UgaXMNCiAgICBzZXJ2 aW5nLg0KICAgIA0KRlA6IFdlIGJyb3VnaHQgdGhpcyB1cCBpbiB0aGUgd2cgYW5kIGV2ZXJ5Ym9k eSBzZWVtZWQgdG8gYmUgb2sgd2l0aCA2NC4gV2UgY2FuIGdvIHVwIHRvIDEyOCBpZiB5b3UgdGhp bmsgaXTigJlzIGJldHRlci4gQWxzbyBjb25zaWRlciB0aGF0IE9TQ09SRSBhcHBlbmRpeCBCMiBo YXMgYSBzaW1pbGFyIHNldHRpbmcgYW5kIGRvZXMgc29tZSBjb25zaWRlcmF0aW9ucyBhYm91dCB0 aGF0LCBtZW50aW9uaW5nIHRoYXQgInR5cGljYWxseSBub25jZXMgb2YgYXQgbGVhc3QgOCBieXRl cyB3aWxsIGJlIHVzZWQiLiBNYXliZSBhZGQgYSByZWZlcmVuY2U/DQpodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjODYxMyNwYWdlLTcyIEkgYnJvdWdodCBpdCB1cCBhcyBvbmUgb2YgdGhl IHBvaW50cyB0aGUgd2cgc2hvdWxkIGFncmVlIG9uLg0KDQo1My4gICAgICAgTm90ZSB0aGF0IHRo ZSB1c2Ugb2YgdGhlIHBheWxvYWQgYW5kIHRoZSBDb250ZW50LUZvcm1hdCBpcyBkaWZmZXJlbnQN CiAgICAgICBmcm9tIHdoYXQgZGVzY3JpYmVkIGluIHNlY3Rpb24gNS44LjEgb2YgW0ktRC5pZXRm LWFjZS1vYXV0aC1hdXRoel0sDQogICAgICAgd2hpY2ggb25seSB0cmFuc3BvcnRzIHRoZSB0b2tl biB3aXRob3V0IGFueSBDQk9SIHdyYXBwaW5nLiAgSW4gdGhpcw0KICAgICAgIHByb2ZpbGUsIHRo ZSBjbGllbnQgTVVTVCB3cmFwIHRoZSB0b2tlbiBhbmQgTjEgaW4gYSBDQk9SIG1hcC4gIFRoZQ0K ICAgICAgIGNsaWVudCBNVVNUIHVzZSB0aGUgQ29udGVudC1Gb3JtYXQgImFwcGxpY2F0aW9uL2Fj ZStjYm9yIiBkZWZpbmVkIGluDQogICAgICAgc2VjdGlvbiA4LjE0IG9mIFtJLUQuaWV0Zi1hY2Ut b2F1dGgtYXV0aHpdLiAgVGhlIGNsaWVudCBNVVNUIGluY2x1ZGUNCiAgICAgICB0aGUgYWNjZXNz IHRva2VuIHVzaW5nIHRoZSBjb3JyZWN0IENCT1IgbGFiZWwgKGUuZy4sICJjd3QiIGZvciBDV1Qs DQogICAgICAgImp3dCIgZm9yIEpXVCkgYW5kIE4xIHVzaW5nIHRoZSAnY25vbmNlJyBwYXJhbWV0 ZXIgZGVmaW5lZCBpbiBzZWN0aW9uDQogICAgICAgNS4xLjIgb2YgW0ktRC5pZXRmLWFjZS1vYXV0 aC1hdXRoel0uDQogICAgDQogICAgVGhhdCdzIG5vdCB3aGF0IHRoZSAnY25vbmNlJyBwYXJhbWV0 ZXIgaXMgZm9yIC0tICdjbm9uY2UnIGlzIHByb3RlY3RpbmcNCiAgICB0aGUgUlMgYWdhaW5zdCBy ZXBsYXksIGJ1dCBOMSBpcyBwcm90ZWN0aW5nIHRoZSBjbGllbnQuICBJIHRoaW5rIHdlIG5lZWQN CiAgICB0byB1c2UgYSBkaWZmZXJlbnQgbmFtZSAoYW5kIG1heWJlIGRlZmluZSBzb21lIGludGVn ZXIgbWFwIGxhYmVsDQogICAgdmFsdWVzPykgZm9yIHRoaXMgYXV0aHotaW5mbyBQT1NUIGJvZHku DQoNCkZQOiBBcyBtZW50aW9uZWQsIHRoaXMgd2FzIHJhaXNlZCBhcyBhbiBvcGVuIHBvaW50IGFu ZCBvayBieSB0aGUgd2cgKGFuZCBwYXJ0aWN1bGFybHkgTHVkd2lnIGFuZCBKaW0pLg0KICAgIA0K NTQuICAgICAgIFRoZSBhY2Nlc3MgdG9rZW4gTVVTVCBiZSBlbmNyeXB0ZWQsIHNpbmNlIGl0IGlz IHRyYW5zZmVycmVkIGZyb20gdGhlDQogICAgICAgY2xpZW50IHRvIHRoZSBSUyBvdmVyIGFuIHVu cHJvdGVjdGVkIGNoYW5uZWwuDQogICAgDQogICAgVGhpcyBpcyBwcm9iYWJseSB3b3J0aCBzdGF0 aW5nIGluIFNlY3Rpb24gMy4yIGFzIHdlbGwsIHdoZXJlIHdlIGRpc2N1c3MNCiAgICB0aGUgQVMt dG8tQyB0b2tlbiByZXNwb25zZSBpbiBtb3JlIGRldGFpbC4NCiAgICANCkZQOiBPSy4NCg0KNTUu ICAgICAgIE5vdGUgdGhhdCBhIGNsaWVudCBtYXkgYmUgcmVxdWlyZWQgdG8gcmUtUE9TVCB0aGUg YWNjZXNzIHRva2VuLCBzaW5jZQ0KICAgICAgIGFuIFJTIG1heSBkZWxldGUgYSBzdG9yZWQgYWNj ZXNzIHRva2VuLCBkdWUgdG8gbGFjayBvZiBtZW1vcnkuDQogICAgDQogICAgSSdkIHN1Z2dlc3Qg dXNpbmcgdGhlIHBocmFzZSAiYXQgYW55IHRpbWUiIGFuZCBub3RpbmcgdGhhdCB0aGUgY2xpZW50 DQogICAgd2lsbCBkZXRlY3QgdGhpcyBieSByZWNlaXZpbmcgYW4gQVMgUmVxdWVzdCBDcmVhdGlv biBIaW50cyBtZXNzYWdlIHNpbmNlDQogICAgdGhlIFJTIHRyZWF0ZWQgdGhlIHJlcXVlc3QgYXMg YW4gVW5hdXRob3JpemVkIFJlc291cmNlIFJlcXVlc3QsIHBlcmhhcHM6DQogICAgDQogICAgJSAg Tm90ZSB0aGF0IGEgY2xpZW50IG1heSBiZSByZXF1aXJlZCB0byByZS1QT1NUIHRoZSBhY2Nlc3Mg dG9rZW4gaW4NCiAgICAlICBvcmRlciB0byBjb21wbGV0ZSBhIHJlcXVlc3QsIHNpbmNlIGFuIFJT IG1heSBkZWxldGUgYSBzdG9yZWQgYWNjZXNzDQogICAgJSAgdG9rZW4gYXQgYW55IHRpbWUsIGZv ciBleGFtcGxlIGR1ZSB0byBhbGwgc3RvcmFnZSBzcGFjZSBiZWluZw0KICAgICUgIGNvbnN1bWVk LiAgVGhpcyBzaXR1YXRpb24gaXMgZGV0ZWN0ZWQgYnkgdGhlIGNsaWVudCB3aGVuIGl0IHJlY2Vp dmVzDQogICAgJSAgYW4gQVMgUmVxdWVzdCBDcmVhdGlvbiBIaW50cyByZXNwb25zZS4NCiAgICAN CkZQOiBPSy4NCg0KNTYuICAgICAgICAgICAgIFBheWxvYWQ6DQogICAgICAgICAgICAgICB7DQog ICAgICAgICAgICAgICAgICJhY2Nlc3NfdG9rZW4iOiBoJ2E1MDM3Njc0NjU2ZDcwNTM2NTZlNzMg Li4uJw0KICAgICAgICAgICAgICAocmVtYWluZGVyIG9mIGFjY2VzcyB0b2tlbiBvbWl0dGVkIGZv ciBicmV2aXR5KScsDQogICAgICAgICAgICAgICAgICJjbm9uY2UiOiBoJzAxOGEyNzhmN2ZhYWI1 NWEnDQogICAgICAgICAgICAgICB9DQogICAgDQogICAgVGhpcyBkb2VzIG5vdCBhcHBlYXIgdG8g YmUgdXNpbmcgZWl0aGVyIGEgImN3dCIgbGFiZWwgb3IgImp3dCIgbGFiZWwsIGFzDQogICAgdGhl IHNlY29uZCBwYXJhZ3JhcGggb2YgdGhlIHNlY3Rpb24gd291bGQgaGF2ZSB1cyB1c2luZy4NCg0K RlA6IE9LLiBXaWxsIHVzZSAiY3d0Ii4NCiAgICANCiAgICBTZWN0aW9uIDQuMg0KICAgIA0KNTcu ICAgICAgIHRva2VuLiAgSWYgdGhlIHRva2VuIGlzIHZhbGlkLCB0aGUgUlMgTVVTVCByZXNwb25k IHRvIHRoZSBQT1NUDQogICAgICAgcmVxdWVzdCB3aXRoIDIuMDEgKENyZWF0ZWQpLiAgSWYgdGhl IHRva2VuIGlzIHZhbGlkIGJ1dCBpcyBhc3NvY2lhdGVkDQogICAgDQogICAgV2UgcHJvYmFibHkg ZG9uJ3QgbmVlZCB0byByZXBlYXQgdGhlIG5vcm1hdGl2ZSByZXF1aXJlbWVudHMgZnJvbQ0KICAg IHRoZSBjb3JlIGZyYW1ld29yayB3aXRoIG5vcm1hdGl2ZSBrZXl3b3JkcyBhZ2Fpbi4NCg0KRlA6 IE9LLg0KICAgIA0KNTguICAgICAgIHRvIGNsYWltcyB0aGF0IHRoZSBSUyBjYW5ub3QgcHJvY2Vz cyAoZS5nLiwgYW4gdW5rbm93biBzY29wZSksIG9yIGlmDQogICAgICAgYW55IG9mIHRoZSBleHBl Y3RlZCBwYXJhbWV0ZXJzIGluIHRoZSBPU0NPUkVfU2VjdXJpdHlfQ29udGV4dCBpcw0KICAgIA0K ICAgIEhtbSwgImFzc29jaWF0ZWQgdG8gY2xhaW1zIHRoYXQgdGhlIFJTIGNhbm5vdCBwcm9jZXNz IiBzb3VuZHMgbGlrZSB3ZSdyZQ0KICAgIHRlbGxpbmcgdGhlIFJTIHRvIGFib3J0IGlmIHRoZSB0 b2tlbiBpbmNsdWRlcyBhbnkgdW5yZWNvZ25pemVkIGNsYWltcywNCiAgICB3aGljaCBJSVVDIGlz IGF0IG9kZHMgd2l0aCB0aGUgT0F1dGggMi4wIHBoaWxvc29waHkgb2YgaWdub3JpbmcNCiAgICB1 bnJlY29nbml6ZWQgcGFyYW1ldGVycy4gIChIb3BlZnVsbHkgc29tZW9uZSB3aWxsIGNvcnJlY3Qg bWUgaWYgSSdtDQogICAgbWlzcmVtZW1iZXJpbmcgdGhhdC4pDQoNCkZQOiBUaGlzIHBhcmFncmFw aCBpcyBtZWFudCB0byBtaXJyb3Igd2hhdCBzcGVjaWZpZWQgaW4gNS44LjEuMSBvZiBhY2Utb2F1 dGgtYXV0aHo6DQpJZiB0aGUgY2xhaW1zIGNhbm5vdCBiZSBvYnRhaW5lZCB0aGUgUlMgTVVTVCBk aXNjYXJkIHRoZSB0b2tlbg0KICAgICAgYW5kLCBpbiBjYXNlIG9mIGFuIGludGVyYWN0aW9uIHZp YSB0aGUgYXV0aHotaW5mbyBlbmRwb2ludCwgcmV0dXJuDQogICAgICBhbiBlcnJvciBtZXNzYWdl IHdpdGggYSByZXNwb25zZSBjb2RlIGVxdWl2YWxlbnQgdG8gdGhlIENvQVAgY29kZQ0KICAgICAg NC4wMCAoQmFkIFJlcXVlc3QpLg0KTmV4dCwgdGhlIFJTIE1VU1QgdmVyaWZ5IGNsYWltcywgaWYg cHJlc2VudCwgY29udGFpbmVkIGluIHRoZSBhY2Nlc3MNCiAgIHRva2VuLiAgRXJyb3JzIGFyZSBy ZXR1cm5lZCB3aGVuIGNsYWltIGNoZWNrcyBmYWlsLCBpbiB0aGUgb3JkZXIgb2YNCiAgIHByaW9y aXR5IG9mIHRoaXMgbGlzdDoNCiAgIA0KNTkuICAgICAgIG1pc3NpbmcgKGUuZy4gYW55IG9mIHRo ZSBtYW5kYXRvcnkgcGFyYW1ldGVycyBmcm9tIHRoZSBBUyksIG9yIGlmIGFueQ0KICAgIA0KICAg IG5pdDogY29tbWEgYWZ0ZXIgImUuZy4iLg0KDQpGUDogRG9uZSBpbiBQUg0KICAgIA0KNjAuICAg ICAgIEFkZGl0aW9uYWxseSwgdGhlIFJTIE1VU1QgZ2VuZXJhdGUgYSBub25jZSBOMiB2ZXJ5IHVu bGlrZWx5IHRvIGhhdmUNCiAgICAgICBiZWVuIHByZXZpb3VzbHkgdXNlZCB3aXRoIHRoZSBzYW1l IGlucHV0IGtleWluZyBtYXRlcmlhbCwgYW5kIHNlbmQgaXQNCiAgICAgICB3aXRoaW4gdGhlIDIu MDEgKENyZWF0ZWQpIHJlc3BvbnNlLiAgVGhlIHBheWxvYWQgb2YgdGhlIDIuMDENCiAgICAgICAo Q3JlYXRlZCkgcmVzcG9uc2UgTVVTVCBiZSBhIENCT1IgbWFwIGNvbnRhaW5pbmcgdGhlICdjbm9u Y2UnDQogICAgICAgcGFyYW1ldGVyIGRlZmluZWQgaW4gc2VjdGlvbiA1LjEuMiBvZiBbSS1ELmll dGYtYWNlLW9hdXRoLWF1dGh6XSwgc2V0DQogICAgICAgdG8gTjIuICBUaGlzIHByb2ZpbGUgUkVD T01NRU5EUyB0byB1c2UgYSA2NC1iaXQgbG9uZyByYW5kb20gbnVtYmVyIGFzDQogICAgICAgbm9u Y2UuICBNb3Jlb3ZlciwgaWYgdGhlIE9TQ09SRV9TZWN1cml0eV9Db250ZXh0IGluIHRoZSB0b2tl biBkaWQgbm90DQogICAgDQogICAgQXMgYWJvdmUsIHdlIG5lZWQgdG8gdXNlIGEgZGlmZmVyZW50 IG5hbWUgdGhhbiAnY25vbmNlJywgYXMgaXQncw0KICAgIHBlcmZvcm1pbmcgYSBkaWZmZXJlbnQg cm9sZSAodGhpcyB0aW1lLCBjb250cmlidXRpbmcgZW50cm9weSB0byB0aGUNCiAgICBtYXN0ZXIg c2VjcmV0KS4gIChBbHNvLCBpZiB3ZSBjaGFuZ2Ugb3VyIHJlY29tbWVuZGF0aW9uIGFib3V0IG5v bmNlDQogICAgbGVuZ3RoIGFib3ZlIHdlIHNob3VsZCBkbyBzbyBoZXJlIGFzIHdlbGwsIG9mIGNv dXJzZS4pDQogICAgDQpGUDogT0ssIHBlbmRpbmcgd2cgYWdyZWVtZW50LCBhbmQgT0suDQoNCjYx LiAgICAgICBjb250YWluIGEgJ2NsaWVudElkJyBwYXJhbWV0ZXIsIHRoZSBSUyBNVVNUIGdlbmVy YXRlIGFuIGlkZW50aWZpZXIsDQogICAgICAgdW5pcXVlIGluIHRoZSBzZXQgb2YgYWxsIGl0cyBl eGlzdGluZyBjbGllbnQgaWRlbnRpZmllcnMsIGFuZCBzZW5kIGl0DQogICAgICAgaW4gYSAnY2xp ZW50SWQnIHBhcmFtZXRlciBpbiB0aGUgQ0JPUiBtYXAgYXMgYSBDQk9SIGJzdHIuICBUaGUgUlMg TUFZDQogICAgICAgZ2VuZXJhdGUgYW5kIHNlbmQgYSAnQ2xpZW50SWQnIGlkZW50aWZpZXIgZXZl biB0aG91Z2ggdGhlDQogICAgICAgT1NDT1JFX1NlY3VyaXR5X0NvbnRleHQgY29udGFpbmVkIHN1 Y2ggYSBwYXJhbWV0ZXIsIGluIG9yZGVyIHRvDQogICAgICAgZ3VhcmFudGVlIHRoZSB1bmlxdWVu ZXNzIG9mIHRoZSBjbGllbnQgaWRlbnRpZmllci4gIFRoZSBSUyBNVVNUIHVzZQ0KICAgIA0KICAg IEknbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgdGhlIGNhc2Ugd2hlcmUgdGhlIEFTIHdvdWxkbid0 IGJlIGFibGUgdG8NCiAgICBndWFyYW50ZWUgdW5pcXVlbmVzcyBvZiBDbGllbnRJZCwgYW5kIHdv bmRlciBpZiB3ZSBjb3VsZCBzaW1wbGlmeSBieQ0KICAgIGFsd2F5cyBoYXZpbmcgdGhlIEFTIG1h a2UgSUQgYXNzaWdubWVudC4gIElzIHRoZXJlIHNvbWUgbW9yZQ0KICAgIGJhY2tncm91bmQvdXNh Z2Ugc2NlbmFyaW9zIGhlcmUgdGhhdCBJJ20gbWlzc2luZz8NCiAgICANCkZQOiBObyB0aGF0J3Mg aXQuIFRoZSBjYXNlIEkgd2FzIHRyeWluZyB0byBjb3ZlciBpcyBoYXZpbmcgc2V2ZXJhbCBBUyBj b3ZlciB0aGUgc2FtZSByZXNvdXJjZSBhdCB0aGUgc2FtZSBSUy4gVGhlbiB3ZSB3b3VsZCBoYXZl IHRvIGhhdmUgdGhlbSBzeW5jaHJvbml6ZWQgZm9yIHVuaXF1ZW5lc3Mgb2YgQ2xpZW50SWQuIEJ1 dCB5ZXMuIEFncmVlIG9uIHJlbW92aW5nIHRoaXMgbWVjaGFuaXNtLg0KDQo2Mi4gICAgICAgV2hl biByZWNlaXZpbmcgYW4gdXBkYXRlZCBhY2Nlc3MgdG9rZW4gd2l0aCB1cGRhdGVkIGF1dGhvcml6 YXRpb24NCiAgICAgICBpbmZvcm1hdGlvbiBmcm9tIHRoZSBjbGllbnQgKHNlZSBzZWN0aW9uIFNl Y3Rpb24gMy4xKSwgaXQgaXMNCiAgICAgICBSRUNPTU1FTkRFRCB0aGF0IHRoZSBSUyBvdmVyd3Jp dGVzIHRoZSBwcmV2aW91cyB0b2tlbiwgdGhhdCBpcyBvbmx5DQogICAgICAgdGhlIGxhdGVzdCBh dXRob3JpemF0aW9uIGluZm9ybWF0aW9uIGluIHRoZSB0b2tlbiByZWNlaXZlZCBieSB0aGUgUlMN CiAgICAgICBpcyB2YWxpZC4gIFRoaXMgc2ltcGxpZmllcyBmb3IgdGhlIFJTIHRvIGtlZXAgdHJh Y2sgb2YgYXV0aG9yaXphdGlvbg0KICAgICAgIGluZm9ybWF0aW9uIGZvciBhIGdpdmVuIGNsaWVu dC4NCiAgICANCiAgICBbdGhpcyBzYW1lIHJlY29tbWVuZGF0aW9uIGlzIGFscmVhZHkgaW4gdGhl IGNvcmUgZnJhbWV3b3JrXQ0KICAgIA0KRlA6IE9LLCB3aWxsIHJlbW92ZSBub3JtYXRpdmUgdGV4 dCBhbmQgcmVmZXJlbmNlIGZyYW1ld29yay4NCg0KICAgIFNlY3Rpb24gNC4zDQogICAgDQo2My4g ICAgICAgdGhlICdjbGllbnRJZCcgaW4gdGhlIENCT1IgbWFwIGluIHRoZSBwYXlsb2FkIG9mIHRo ZSByZXNwb25zZS4gIFRoZW4sDQogICAgICAgdGhlIGNsaWVudCBNVVNUIHNldCB0aGUgTWFzdGVy IFNhbHQgb2YgdGhlIFNlY3VyaXR5IENvbnRleHQgY3JlYXRlZA0KICAgICAgIHRvIGNvbW11bmlj YXRlIHdpdGggdGhlIFJTIHRvIHRoZSBjb25jYXRlbmF0aW9uIG9mIHNhbHQsIE4xLCBhbmQgTjIs DQogICAgICAgaW4gdGhpcyBvcmRlcjogTWFzdGVyIFNhbHQgPSBzYWx0IHwgTjEgfCBOMiwgd2hl cmUgfCBkZW5vdGVzIGJ5dGUNCiAgICAgICBzdHJpbmcgY29uY2F0ZW5hdGlvbiwgYW5kIHdoZXJl IHNhbHQgd2FzIHJlY2VpdmVkIGZyb20gdGhlIEFTIGluDQogICAgICAgU2VjdGlvbiAzLjIuICBU aGUgY2xpZW50IE1VU1Qgc2V0IHRoZSBNYXN0ZXIgU2VjcmV0IGFuZCBSZWNpcGllbnQgSUQNCiAg ICANCiAgICBJIHRoaW5rIGl0J3MgZ2VuZXJhbCBiZXN0IHByYWN0aWNlIHRvIHVzZSBhbiBpbmpl Y3RpdmUgbWFwcGluZyBvZiB0aGUgaW5wdXRzDQogICAgdG8gdGhlIE1hc3RlciBTYWx0IHZhbHVl IChpLmUuLCBsZW5ndGgtcHJlZml4ZXMgZm9yIHRoZSB2YXJpb3VzIGZpZWxkcywgc2luY2UNCiAg ICB0aGVyZSBhcmUgbm8gcmVzZXJ2ZWQgb2N0ZXQgdmFsdWVzKS4NCg0KRlA6IE9LLCB1c2luZyBD Qk9SIGVuY29kZWQgYnN0ciAob3IgYjY0IGlmIEpTT04gaXMgdXNlZCkgc2hvdWxkIGZpeCB0aGF0 Lg0KICAgIA0KNjQuICAgICAgIGZyb20gdGhlIHBhcmFtZXRlcnMgcmVjZWl2ZWQgZnJvbSB0aGUg QVMgaW4gU2VjdGlvbiAzLjIuICBUaGUgY2xpZW50DQogICAgICAgTVVTVCBzZXQgdGhlIEFFQUQg QWxnb3JpdGhtLCBJRCBDb250ZXh0LCBIS0RGLCBhbmQgUmVwbGF5IFdpbmRvdyBmcm9tDQogICAg ICAgdGhlIHBhcmFtZXRlcnMgcmVjZWl2ZWQgZnJvbSB0aGUgQVMgaW4gU2VjdGlvbiAzLjIsIGlm IHByZXNlbnQuICBJbg0KICAgICAgIGNhc2UgdGhlc2UgcGFyYW1ldGVycyBhcmUgb21pdHRlZCwg dGhlIGRlZmF1bHQgdmFsdWVzIGFyZSB1c2VkIGFzDQogICAgICAgZGVzY3JpYmVkIGluIHNlY3Rp b24gMy4yIG9mIFtJLUQuaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eV0uICBUaGUNCiAgICANCiAg ICBBaCwgb2theTsgSSdkIGFza2VkIGFib3V0IGRlZmF1bHQgdmFsdWVzIGVhcmxpZXIuICBUaGF0 IHNhaWQsIGlmIHN0b2NrIE9TQ09SRQ0KICAgIGV2ZXIgY2hhbmdlcyB0aGUgZGVmYXVsdHMgd2Un ZCBoYXZlIHRvIGNvbWUgdXAgd2l0aCBhIGNvbXBhdGliaWxpdHkgc3RvcnkgZm9yDQogICAgY29t bXVuaWNhdGlvbiBiZXR3ZWVuIG9sZC9uZXcgbm9kZXMuDQogICAgDQpGUDogWWVzLiBNYXliZSBh ZGRpbmcgYSB2ZXJzaW9uIG51bWJlciB0byB0aGlzIGNvbnRleHQgc3RydWN0dXJlPyBJIHRoaW5r IHRoaXMgaXMgYSBnb29kIGlkZWEuDQoNCjY1LiAgICAgICBjbGllbnQgTVVTVCBzZXQgdGhlIFNl bmRlciBJRCBmcm9tIHRoZSAnY2xpZW50SWQgaW4gdGhlIDIuMDENCiAgICAgICAoQ3JlYXRlZCkg cmVzcG9uc2UsIGlmIHByZXNlbnQ7IG90aGVyd2lzZSwgdGhlIGNsaWVudCBNVVNUIHNldCB0aGUN CiAgICAgICBTZW5kZXIgSUQgZnJvbSB0aGUgcGFyYW1ldGVycyByZWNlaXZlZCBmcm9tIHRoZSBB UyBpbiBTZWN0aW9uIDMuMi4NCiAgICANCiAgICBbQXMgd3JpdHRlbiwgdGhpcyBoYXMgdGhlIGNs aWVudElkIGZyb20gdGhlIFJTIHRha2UgcHJlY2VkZW5jZSBvdmVyIHRoZSBvbmUNCiAgICBmcm9t IHRoZSBBUyB3aGVuIGJvdGggYXJlIHByZXNlbnQuICBJIHVuZGVyc3RhbmQgdGhhdCB0aGUgY2xh aW1lZA0KICAgIGp1c3RpZmljYXRpb24gaXMgZm9yIHRoZSBSUyB0byBiZSBhYmxlIHRvIGVuZm9y Y2UgY2xpZW50SWQgdW5pcXVlbmVzcywgYnV0IGl0DQogICAgc3RpbGwgZmVlbHMgcmlza3ksIHNp bmNlIHRoZSB2YWx1ZSBmcm9tIHRoZSBSUyBpcyB1bmF1dGhlbnRpY2F0ZWQuXQ0KDQpGUDogTGV0 J3MgcmVtb3ZlIHRoaXMgbWVjaGFuaXNtLg0KICAgIA0KNjYuICAgICAgIElmIGFueSBvZiB0aGUg ZXhwZWN0ZWQgcGFyYW1ldGVycyBpcyBtaXNzaW5nIChlLmcuIGFueSBvZiB0aGUNCiAgICAgICBt YW5kYXRvcnkgcGFyYW1ldGVycyBmcm9tIHRoZSBBUywgb3IgdGhlICdjbGllbnRJZCcsIGVpdGhl ciByZWNlaXZlZA0KICAgICAgIGZyb20gdGhlIEFTIG9yIGluIHRoZSAyLjAxIChDcmVhdGVkKSBy ZXNwb25zZSBmcm9tIHRoZSBSUyksIHRoZQ0KICAgICAgIGNsaWVudCBNVVNUIHN0b3AgdGhlIGV4 Y2hhbmdlLCBhbmQgTVVTVCBOT1QgZGVyaXZlIHRoZSBTZWN1cml0eQ0KICAgICAgIENvbnRleHQu ICBUaGUgY2xpZW50IE1BWSByZXN0YXJ0IHRoZSBleGNoYW5nZSwgdG8gZ2V0IHRoZSBjb3JyZWN0 DQogICAgICAgc2VjdXJpdHkgbWF0ZXJpYWwuDQogICAgDQogICAgSSB0aGluayB0aGlzIG1lYW5z ICJyZXN0YXJ0IGF0IHRoZSBBUyIgYnV0IGl0J3MgcHJvYmFibHkgd29ydGggYmVpbmcgdmVyeQ0K ICAgIGV4cGxpY2l0IGFib3V0IGl0Lg0KDQpGUDogWWVzLCBPSyB3aWxsIGNsYXJpZnkuDQoNCiAg ICBBbHNvLCBpcyB0aGVyZSBhbnl0aGluZyB0byBiZSBzYWlkIGFib3V0IHJhdGUtbGltaXRpbmcv YmFja29mZiBmb3IgcGVyc2lzdGVudA0KICAgIG1pc3NpbmcgcGFyYW1ldGVycz8NCg0KRlA6IE9L LCB3aWxsIGFkZCBhIHNlbnRlbmNlIGFib3V0IHRoYXQuDQogICAgDQo2Ny4gICAgICAgQWZ0ZXIg c2VuZGluZyB0aGUgMi4wMSAoQ3JlYXRlZCkgcmVzcG9uc2UsIHRoZSBSUyBNVVNUIHNldCB0aGUg TWFzdGVyDQogICAgICAgU2FsdCBvZiB0aGUgU2VjdXJpdHkgQ29udGV4dCBjcmVhdGVkIHRvIGNv bW11bmljYXRlIHdpdGggdGhlIGNsaWVudA0KICAgICAgIHRvIHRoZSBjb25jYXRlbmF0aW9uIG9m IHNhbHQsIE4xLCBhbmQgTjIsIGluIHRoaXMgb3JkZXI6IE1hc3RlciBTYWx0DQogICAgICAgPSBz YWx0IHwgTjEgfCBOMiwgd2hlcmUgfCBkZW5vdGVzIGJ5dGUgc3RyaW5nIGNvbmNhdGVuYXRpb24s IGFuZA0KICAgIA0KICAgIFtJdCBtaWdodCBiZSB3b3J0aCBicmVha2luZyB0aGlzIGNvbXB1dGF0 aW9uIG9mZiBpbnRvIGEgc3RhbmRhbG9uZSBwaWVjZSBvZg0KICAgIHRleHQgdGhhdCBhcHBsaWVz IHRvIGJvdGggQyBhbmQgUlMsIGluY2x1ZGluZyB0aGUgZWRpdHMgZm9yIGluamVjdGl2aXR5Ll0N CiAgICANCkZQOiBPSw0KDQo2OC4gICAgICAgd2hlcmUgc2FsdCB3YXMgcmVjZWl2ZWQgZnJvbSB0 aGUgQVMgaW4gU2VjdGlvbiA0LjIuICBUaGUgUlMgTVVTVCBzZXQNCiAgICAgICB0aGUgTWFzdGVy IFNlY3JldCwgU2VuZGVyIElEIGFuZCBSZWNpcGllbnQgSUQgZnJvbSB0aGUgcGFyYW1ldGVycywN CiAgICAgICByZWNlaXZlZCBmcm9tIHRoZSBjbGllbnQgaW4gdGhlIGFjY2VzcyB0b2tlbiBpbiBT ZWN0aW9uIDQuMSBhZnRlcg0KICAgIA0KICAgIG5pdDogSSdkIHBsYWNlIHRoZSBlbXBoYXNpcyBt b3JlIG9uICJpbiB0aGUgYWNjZXNzIHRva2VuIiBvciBldmVuICJmcm9tIHRoZQ0KICAgIEFTIiBy YXRoZXIgdGhhbiAiZnJvbSB0aGUgY2xpZW50IiAtLSB0aGUgUlMvQVMgcHJlZXN0YWJsaXNoZWQg cmVsYXRpb25zaGlwIGlzDQogICAgd2hhdCBhdXRoZW50aWNhdGVzIHRoZXNlIHZhbHVlcy4NCg0K RlA6IERvbmUgaW4gUFI6ICJmcm9tIHRoZSBBUyBmb3J3YXJkZWQgYnkgdGhlIGNsaWVudCIuDQog ICAgDQo2OS4gICAgICAgdmFsaWRhdGlvbiBvZiB0aGUgdG9rZW4gYXMgc3BlY2lmaWVkIGluIFNl Y3Rpb24gNC4yLiAgVGhlIFJTIE1VU1Qgc2V0DQogICAgDQogICAgRG9lcyBTZWN0aW9uIDQuMiBy ZWFsbHkgc2F5IG11Y2ggYWJvdXQgdmFsaWRhdGlvbiBvdGhlciB0aGFuICJSUyBNVVNUIHZlcmlm eQ0KICAgIHRoZSB2YWxpZGl0eSBvZiB0aGUgdG9rZW4iPw0KDQpGUDogd2VsbCwgdGhhdCBhbmQg cG9pbnRzIHRvIDUuOC4xIG9mIGFjZS1vYXV0aC1hdXRoei4gSSBwb2ludGVkIHRvIHRoZSBmcmFt ZXdvcmsgbm90IHRvIGR1cGxpY2F0ZSB0aGUgcmVmZXJlbmNlLCBidXQgd2UgY2FuIGRvIHRoYXQg aWYgeW91IHRoaW5rIGl04oCZcyBiZXN0Lg0KICAgIA0KNzAuICAgICAgIFtJLUQuaWV0Zi1jb3Jl LW9iamVjdC1zZWN1cml0eV0uICBBZnRlciB0aGF0LCB0aGUgUlMgTVVTVCBkZXJpdmUgdGhlDQog ICAgICAgY29tcGxldGUgU2VjdXJpdHkgQ29udGV4dCBmb2xsb3dpbmcgc2VjdGlvbiAzLjIuMSBv Zg0KICAgICAgIFtJLUQuaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eV0sIGFuZCBNVVNUIGFzc29j aWF0ZSB0aGlzIFNlY3VyaXR5DQogICAgICAgQ29udGV4dCB3aXRoIHRoZSBhdXRob3JpemF0aW9u IGluZm9ybWF0aW9uIGZyb20gdGhlIGFjY2VzcyB0b2tlbi4NCiAgICANCiAgICBzaWRlIG5vdGU6 IGl0J3Mgc29tZXRpbWVzIHVzZWZ1bCBhcyBhIHJoZXRvcmljYWwgZGV2aWNlIHRvIGhhdmUgYSBk aXNjdXNzaW9uDQogICAgb2YgdGhlIGFic3RyYWN0IGRhdGEgbW9kZWwgdGhlIFJTIHVzZXMgLS0g aW4gdGhpcyBjYXNlLCB0aGF0IGl0IG1haW50YWlucyBhDQogICAgY29sbGVjdGlvbiBvZiBTZWN1 cml0eSBDb250ZXh0cyB3aXRoIGFzc29jaWF0ZWQgYXV0aG9yaXphdGlvbiBpbmZvcm1hdGlvbiwN CiAgICBmb3IgYWxsIHRoZSBjbGllbnRzIHRoYXQgaXQncyBjdXJyZW50bHkgY29tbXVuaWNhdGlu ZyB3aXRoLCBhbmQgdGhhdCB0aGUNCiAgICBhdXRob3JpemF0aW9uIGluZm9ybWF0aW9uIGlzIHBv bGljeSB0aGF0J3MgdXNlZCBhcyBpbnB1dCB0byBwcm9jZXNzaW5nDQogICAgcmVxdWVzdHMgZnJv bSB0aG9zZSBjbGllbnRzLiAgT3RoZXJ3aXNlLCB0aGlzIHRleHQgYWJvdXQgIk1VU1QgYXNzb2Np YXRlIiBjYW4NCiAgICBiZSBhIGJpdCB2YWd1ZSB0byB0aGUgcmVhZGVyLg0KDQpGUDogT0ssIHdp bGwgYWRkIHRoaXMgY2xhcmlmaWNhdGlvbiBpbiB0aGlzIHNlY3Rpb24uDQogICAgDQo3MS4gICAg ICAgVGhlIFJTIHRoZW4gdXNlcyB0aGlzIFNlY3VyaXR5IENvbnRleHQgdG8gdmVyaWZ5IHRoZSBy ZXF1ZXN0IGFuZCBzZW5kDQogICAgICAgcmVzcG9uc2VzIHRvIEMgdXNpbmcgT1NDT1JFLiAgSWYg T1NDT1JFIHZlcmlmaWNhdGlvbiBmYWlscywgZXJyb3INCiAgICANCiAgICAobml0Pykgd2hhdCBp cyAidGhlIHJlcXVlc3QiPyAgSSBkb24ndCB0aGluayB3ZSd2ZSB0YWxrZWQgYWJvdXQgYSBzcGVj aWZpYw0KICAgIE9TQ09SRSByZXF1ZXN0IHlldCwgc28gdGhpcyB3b3VsZCBwcm9iYWJseSBiZSBi ZXR0ZXIgaWYgdGFsa2luZyBhYm91dCBnZW5lcmljDQogICAgaW5jb21pbmcgcmVxdWVzdHMgZnJv bSBhIGdpdmVuIGNsaWVudC4NCiAgICANCkZQOiBEb25lIGluIFBSOiAidmVyaWZ5IHJlcXVlc3Rz IGFuZCBzZW5kcyByZXNwb25zZXMiLg0KDQo3Mi4gICAgICAgcmVzcG9uc2VzIGFyZSB1c2VkLCBh cyBzcGVjaWZpZWQgaW4gc2VjdGlvbiA4IG9mDQogICAgICAgW0ktRC5pZXRmLWNvcmUtb2JqZWN0 LXNlY3VyaXR5XS4gIEFkZGl0aW9uYWxseSwgaWYgT1NDT1JFDQogICAgICAgdmVyaWZpY2F0aW9u IHN1Y2NlZWRzLCB0aGUgdmVyaWZpY2F0aW9uIG9mIGFjY2VzcyByaWdodHMgaXMgcGVyZm9ybWVk DQogICAgICAgYXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gU2VjdGlvbiA0LjQuICBUaGUgUlMgTVVT VCBOT1QgdXNlIHRoZQ0KICAgICAgIFNlY3VyaXR5IENvbnRleHQgYWZ0ZXIgdGhlIHJlbGF0ZWQg dG9rZW4gaGFzIGV4cGlyZWQsIGFuZCBNVVNUDQogICAgICAgcmVzcG9uZCB3aXRoIGEgdW5wcm90 ZWN0ZWQgNC4wMSAoVW5hdXRob3JpemVkKSBlcnJvciBtZXNzYWdlLg0KICAgIA0KICAgIG5pdDog SSBzdWdnZXN0ICJNVVNUIHJlc3BvbmQgd2l0aCBhbiB1bnByb3RlY3RlZCBbLi4uXSBlcnJvciBt ZXNzYWdlIHRvDQogICAgcmVxdWVzdHMgcmVjZWl2ZWQgdGhhdCBjb3JyZXNwb25kIHRvIGEgc2Vj dXJpdHkgY29udGV4dCB3aXRoIGFuIGV4cGlyZWQNCiAgICB0b2tlbiIgdG8gdGllIGl0IGJhY2sg dG8gd2hpY2ggcmVxdWVzdHMgYXJlIGFmZmVjdGVkLg0KDQpGUDogRG9uZSBpbiBQUi4NCiAgICAN CjczLiAgICAgICBJZiB0aGUgZXhjaGFuZ2Ugd2FzIGFuIHVwZGF0ZSBvZiBhY2Nlc3MgcmlnaHRz LCBpLmUuIGEgbmV3IFNlY3VyaXR5DQogICAgDQogICAgbml0OiBjb21tYSBhZnRlciAiaS5lLiIu DQogICAgDQpGUDogRG9uZSBpbiBQUi4NCg0KNzQuICAgICAgIENvbnRleHQgd2FzIGRlcml2ZWQg ZnJvbSBhIGNsaWVudCB0aGF0IGFscmVhZHkgaGFkIGEgU2VjdXJpdHkgQ29udGV4dA0KICAgICAg IGluIHBsYWNlLCB0aGUgaXMgUkVDT01NRU5ERUQgdG8gZGVsZXRlIHRoZSBvbGQgU2VjdXJpdHkg Q29udGV4dCBhZnRlcg0KICAgICAgIE9TQ09SRSB2ZXJpZmljYXRpb24gYW5kIHZlcmlmaWNhdGlv biBvZiBhY2Nlc3MgcmlnaHRzIHN1Y2NlZWQuICBUaGUNCiAgICAgICBSUyBNVVNUIGRlbGV0ZSB0 aGUgU2VjdXJpdHkgQ29udGV4dCBpZiBpdCBkZWxldGVzIHRoZSBhY2Nlc3MgdG9rZW4NCiAgICAg ICBhc3NvY2lhdGVkIHRvIGl0Lg0KICAgIA0KICAgIEknbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQg d2hhdCB0aGUgd29ya2Zsb3cgaXMsIGhlcmUgLS0gSSBhc3N1bWUgdGhhdCB0aGUNCiAgICBkZWxl dGlvbiBvZiB0aGUgb2xkIHNlY3VyaXR5IGNvbnRleHQgb2NjdXJzIGFmdGVyIGEgc3VjY2Vzc2Z1 bCB1cGRhdGUgdmlhDQogICAgdGhlIGF1dGh6LWluZm8gZW5kcG9pbnQgKGFzIG9wcG9zZWQgdG8g c29tZSBwYXJ0aWN1bGFyIE9TQ09SRS1wcm90ZWN0ZWQNCiAgICByZXF1ZXN0KSwgYnV0IEkgZG9u J3Qga25vdyB3aGF0ICJ2ZXJpZmljYXRpb24gb2YgYWNjZXNzIHJpZ2h0cyIgY291bGQgYmUNCiAg ICBwZXJmb3JtZWQgYXQgdGhhdCB0aW1lLiAgQXJlbid0IGFjY2VzcyByaWdodHMgbW9zdGx5IHRp ZWQgdG8gYSBzcGVjaWZpYw0KICAgIG9wZXJhdGlvbiwgb3IgaXMgdGhpcyBqdXN0IHN1cHBvc2Vk IHRvIGJlIGEgbW9yZSBnZW5lcmljIGF1ZGllbmNlL3Njb3BlDQogICAgY2hlY2s/DQoNCkZQOiBU aGUgUlMgZGVsZXRlcyB0aGUgb2xkIHRva2VuIGFuZCB0aGUgb2xkIHNlY3VyaXR5IGNvbnRleHQg b25seSBhZnRlciBzdWNjZXNzZnVsbHkgcHJvY2Vzc2luZyBhIHJlcXVlc3QgZnJvbSB0aGUgY2xp ZW50LCB1c2luZyB0aGUgbmV3IHRva2VuIGFuZCBzZWN1cml0eSBjb250ZXh0LiBUaGF0IGluY2x1 ZGVzIE9TQ09SRSB2ZXJpZmljYXRpb24gYW5kIGFsc28gYWNjZXNzIHJpZ2h0cyB2ZXJpZmljYXRp b24sIGxpa2UgYW55IG5vcm1hbCByZXF1ZXN0LiBJcyB0aGF0IG5vdCBjbGVhcj8gSG93IHRvIG1h a2UgaXQgY2xlYXJlcj8NCiAgICANCiAgICBTZWN0aW9uIDQuNA0KICAgIA0KNzUuICAgICAgIFRo ZSBSUyBNVVNUIGZvbGxvdyB0aGUgcHJvY2VkdXJlcyBkZWZpbmVkIGluIHNlY3Rpb24gNS44LjIg b2YNCiAgICAgICBbSS1ELmlldGYtYWNlLW9hdXRoLWF1dGh6XTogaWYgYW4gUlMgcmVjZWl2ZXMg YW4gT1NDT1JFLXByb3RlY3RlZA0KICAgICAgIHJlcXVlc3QgZnJvbSBhIGNsaWVudCwgdGhlbiB0 aGUgUlMgcHJvY2Vzc2VzIGl0IGFjY29yZGluZyB0bw0KICAgICAgIFtJLUQuaWV0Zi1jb3JlLW9i amVjdC1zZWN1cml0eV0uICBJZiBPU0NPUkUgdmVyaWZpY2F0aW9uIHN1Y2NlZWRzLA0KICAgICAg IGFuZCB0aGUgdGFyZ2V0IHJlc291cmNlIHJlcXVpcmVzIGF1dGhvcml6YXRpb24sIHRoZSBSUyBy ZXRyaWV2ZXMgdGhlDQogICAgDQogICAgbml0KD8pOiBpcyBpdCBhcHByb3ByaWF0ZSB0byBzYXkg InJlcXVpcmVzIGFkZGl0aW9uYWwgYXV0aG9yaXphdGlvbiIgKG92ZXINCiAgICB0aGUgaW1wbGlj aXQgYXV0aG9yaXphdGlvbiBnaXZlbiB0byBhbnkgYXV0aGVudGljYXRlZCBjbGllbnQpPyAgSSdt IG5vdCBzdXJlDQogICAgaWYgdGhhdCB3b3VsZCBiZSBjb25mdXNpbmcgb3Igbm90Lg0KICAgIA0K RlA6IEkgd291bGQgdGhpbmsgdGhpcyBpcyBtb3JlIGNvbmZ1c2luZyB0aGFuIGNsYXJpZnlpbmcg YmVjYXVzZSB3ZSBkb27igJl0IHRhbGsgYWJvdXQgaW1wbGljaXQgYXV0aG9yaXphdGlvbiBpbiB0 aGlzIGRvY3VtZW50LiBXZSBjYW4gbWFrZSB0aGlzIGNoYW5nZSBpZiBvdGhlciBwZW9wbGUgYWdy ZWUgdGhhdCB0aGlzIGZvcm11bGF0aW9uIGlzIGJldHRlci4NCg0KNzYuICAgICAgIGF1dGhvcml6 YXRpb24gaW5mb3JtYXRpb24gZnJvbSB0aGUgYWNjZXNzIHRva2VuIGFzc29jaWF0ZWQgdG8gdGhl DQogICAgICAgU2VjdXJpdHkgQ29udGV4dC4gIFRoZSBSUyB0aGVuIE1VU1QgdmVyaWZ5IHRoYXQg dGhlIGF1dGhvcml6YXRpb24NCiAgICAgICBpbmZvcm1hdGlvbiBjb3ZlcnMgdGhlIHJlc291cmNl IGFuZCB0aGUgYWN0aW9uIHJlcXVlc3RlZC4NCiAgICANCiAgICBJbiB0aGUgdmVpbiBvZiBteSBw cmV2aW91cyBub3RlIGFib3V0IGFuIGFic3RyYWN0IGRhdGEgbW9kZWwsIHdlIG1heSBub3Qgd2Fu dA0KICAgIHRvIGJlIG92ZXJseSBwcmVzY3JpcHRpdmUgYWJvdXQgInJldHJpZXZlcyBbLi4uXSBm cm9tIHRoZSBhY2Nlc3MgdG9rZW4iLg0KICAgIFBlci1yZXF1ZXN0IGludHJvc3BlY3Rpb24gaXMg YWxsb3dlZCwgYXMgaXMgY2FjaGluZyB0aGUgYXV0aG9yaXphdGlvbg0KICAgIGluZm9ybWF0aW9u IGluIGEgbm9uLXRva2VuIGxvY2FsIGRhdGFzdG9yZS4NCg0KRlA6IE9rLCBJIHVuZGVyc3RhbmQg YnV0IEkgYW0gbm90IHN1cmUgaG93IHRvIGltcGxlbWVudCB0aGlzIGNvbW1lbnQuIOKAnFJldHJp ZXZl4oCdIG1heSBiZSBtaXNpbnRlcnByZXRlZCwgYnV0IGluIG15IG1pbmQgaXQgY2FuIG1lYW4g Ym90aCBieSBsb29raW5nIHVwIGNhY2hpbmcgaW5mbyBhcyB3ZWxsIGFzIGludHJvc3BlY3Rpbmcu IEhvdyB0byBtYWtlIHRoaXMgY2xlYXJlcj8NCg0KICAgIEknZCBhbHNvIGNvbnNpZGVyIHJlcGhy YXNpbmcgdG8gIk1VU1QgdmVyaWZ5IHRoYXQgdGhlIHJlc291cmNlIGFuZCBhY3Rpb24NCiAgICBy ZXF1ZXN0ZWQgYXJlIGF1dGhvcml6ZWQiLCBzaW5jZSAiY292ZXJzIiBpcyBwZXJoYXBzIGEgbGl0 dGxlIHZhZ3VlLg0KICAgIA0KRlA6IE9LDQoNCjc3LiAgICAgICBUaGUgcmVzcG9uc2UgY29kZSBN VVNUIGJlIDQuMDEgKFVuYXV0aG9yaXplZCkgaW4gY2FzZSB0aGUgY2xpZW50IGhhcw0KICAgICAg IG5vdCB1c2VkIHRoZSBTZWN1cml0eSBDb250ZXh0IGFzc29jaWF0ZWQgd2l0aCB0aGUgYWNjZXNz IHRva2VuLCBvciBpZg0KICAgICAgIFJTIGhhcyBubyB2YWxpZCBhY2Nlc3MgdG9rZW4gZm9yIHRo ZSBjbGllbnQuICBJZiBSUyBoYXMgYW4gYWNjZXNzDQogICAgDQogICAgVGhlIGNhdXNhbGl0eSBo ZXJlIHNlZW1zIGEgYml0IHdlaXJkOyBob3cgd291bGQgdGhlIFJTIGtub3cgd2hhdCB0b2tlbiB3 YXMNCiAgICBpbnRlbmRlZCBqdXN0IGZyb20gYW4gT1NDT1JFIHJlcXVlc3QgdGhhdCdzIHVzaW5n IGEgcmFuZG9tIG9yIGRpZmZlcmVudA0KICAgIHNlY3VyaXR5IGNvbnRleHQ/DQoNCkZQOiBUaGUg UlMgbmVlZHMgdG8ga2VlcCB0aGlzIGFzc29jaWF0aW9uIGJldHdlZW4gU2VjdXJpdHkgQ29udGV4 dCBhbmQgdG9rZW4uIFRoaXMgZmlyc3Qgc2VjdGlvbiBjb3ZlcnMgdGhlIGNhc2Ugd2hlcmUgdGhl IGNsaWVudCBpcyB1c2luZyBhIHNlYyBjdHggbm90IGFzc29jaWF0ZWQgdG8gYW55IHRva2VuIG9y IHdoZXJlIHRoYXQgc2VjIGN0eCB3YXMgbm90IHVzZWQgYmVmb3JlIChzbyB0aGUgZnVsbCBPU0NP UkUgc2V0dXAgZGlkIG5vdCBnbyB0aHJvdWdoKS4gRGlmZmVyZW50ICjigJx2YWxpZOKAnSkgc2Vj dXJpdHkgY29udGV4dCBhc3NvY2lhdGVkIHRvIGEgdG9rZW4gaXMgY292ZXJlZCBpbiB0aGUgbmV4 dCBzZWN0aW9uLiBJcyB0aGVyZSBhbnl0aGluZyBJIGFtIG1pc3NpbmcgaGVyZT8NCiAgICANCjc4 LiAgICAgICB0b2tlbiBmb3IgdGhlIGNsaWVudCBidXQgbm90IGZvciB0aGUgcmVzb3VyY2UgdGhh dCB3YXMgcmVxdWVzdGVkLCBSUw0KICAgICAgIE1VU1QgcmVqZWN0IHRoZSByZXF1ZXN0IHdpdGgg YSA0LjAzIChGb3JiaWRkZW4pLiAgSWYgUlMgaGFzIGFuIGFjY2Vzcw0KICAgIA0KICAgIEknZCBz dWdnZXN0IHJlcGhyYXNpbmcgdGhpcyB0byBiZSBpbiB0ZXJtcyBvZiBhdXRob3JpemF0aW9uIHJh dGhlciB0aGFuDQogICAgInRva2VuIGZvciBYIiwgcGVyaGFwcyBhcyAiaWYgdGhlIFJTIGhhcyBh biBhY2Nlc3MgdG9rZW4gZm9yIHRoZSBjbGllbnQgYnV0DQogICAgbm8gYWN0aW9ucyBhcmUgYXV0 aG9yaXplZCBvbiB0aGUgdGFyZ2V0IHJlc291cmNlIg0KDQpGUDogT0sNCiAgICANCjc5LiAgICAg ICB0b2tlbiBmb3IgdGhlIGNsaWVudCBidXQgaXQgZG9lcyBub3QgY292ZXIgdGhlIGFjdGlvbiB0 aGF0IHdhcw0KICAgICAgIHJlcXVlc3RlZCBvbiB0aGUgcmVzb3VyY2UsIFJTIE1VU1QgcmVqZWN0 IHRoZSByZXF1ZXN0IHdpdGggYSA0LjA1DQogICAgICAgKE1ldGhvZCBOb3QgQWxsb3dlZCkuDQog ICAgDQogICAgU2ltaWxhcmx5LCBwZXJoYXBzICJidXQgdGhlIHJlcXVlc3RlZCBhY3Rpb24gaXMg bm90IGF1dGhvcml6ZWQiLg0KDQpGUDogT0sNCiAgICANCiAgICBBbHNvLCBkb24ndCBib3RoIG9m IHRoZXNlIGRlc2NyaXB0aW9ucyBoYXZlIGhpZ2ggb3ZlcmxhcCB3aXRoIFNlY3Rpb24gNS44LjIN CiAgICBvZiB0aGUgY29yZSBmcmFtZXdvcms/ICBJcyBpdCBuZWNlc3NhcnkgdG8gcmVpdGVyYXRl IHRob3NlIGJlaGF2aW9yDQogICAgc3BlY2lmaWNhdGlvbnM/DQoNCkZQOiBZZXMsIHRoaXMgd2hv bGUgc2Vjb25kIHBhcmFncmFwaCByZS1pdGVyYXRlcyB0aGF0IHNlY3Rpb24uIFdlIGNhbiByZW1v dmUgaXQsIHRoZSBvbmx5IHRoaW5nIGxlZnQgd2lsbCBiZSB0byBzcGVjaWZ5IHRoYXQg4oCccGVy Zm9ybWVkIHByb29mLW9mLXBvc3Nlc3Npb27igJ0gPSDigJxoYXZpbmcgYW4gT1NDT1JFIHNlY3Vy aXR5IGNvbnRleHQgZXN0YWJsaXNoZWTigJ0NCiAgICANCiAgICBTZWN0aW9uIDUNCiAgICANCjgw LiAgICBUaGFuayB5b3UgZm9yIGNsZWFybHkgc3RhdGluZyB0aGF0IHRoZSBPU0NPUkUgc2VjdXJp dHkgY29udGV4dHMgYmV0d2VlbiBSUy9BUw0KICAgIGFuZCBDL0FTIG11c3QgYmUgZXN0YWJsaXNo ZWQgaW5kZXBlbmRlbnRseSBvZiBhbnkgb2YgdGhlIG1lY2hhbmlzbXMgZGVmaW5lZA0KICAgIGlu IHRoaXMgZG9jdW1lbnQsIGFuZCB0aGF0IHRoZSBwcm90b2NvbHMgdXNlZCBmb3IgdGhlIEMvUlMs IEMvQVMsIGFuZCBSUy9BUw0KICAgIHN0ZXBzIGNhbiBiZSBzZWxlY3RlZCBpbmRlcGVuZGVudGx5 Lg0KDQpGUDogR29vZCB0aGF0IGl0J3MgY2xlYXIuDQogICAgDQo4MS4gICAgICAgRnVydGhlcm1v cmUgdGhlIHJlcXVlc3RpbmcgZW50aXR5IGFuZCB0aGUgQVMgY29tbXVuaWNhdGUgdXNpbmcgT1ND T1JFDQogICAgICAgKFtJLUQuaWV0Zi1jb3JlLW9iamVjdC1zZWN1cml0eV0pIHRocm91Z2ggdGhl IGludHJvc3BlY3Rpb24gZW5kcG9pbnQNCiAgICAgICBhcyBzcGVjaWZpZWQgaW4gc2VjdGlvbiA1 Ljcgb2YgW0ktRC5pZXRmLWFjZS1vYXV0aC1hdXRoel0gYW5kIHRocm91Z2gNCiAgICAgICB0aGUg dG9rZW4gZW5kcG9pbnQgYXMgc3BlY2lmaWVkIGluIHNlY3Rpb24gNS42IG9mDQogICAgICAgW0kt RC5pZXRmLWFjZS1vYXV0aC1hdXRoel0uDQogICAgDQogICAgSSdtIG5vdCBlbnRpcmVseSBzdXJl IHdoYXQgdGhpcyBzZW50ZW5jZSBpcyB0cnlpbmcgdG8gc2F5IC0tIGl0IGNvbWVzIGFjcm9zcw0K ICAgIGEgbGl0dGxlIGJpdCBhcyBzYXlpbmcgdGhhdCB3aGVuIHRoaXMgZG9jdW1lbnQgaXMgaW4g dXNlLCB0aGUgaW5kaWNhdGVkDQogICAgaW50ZXJhY3Rpb25zIGFsc28gdXNlIE9TQ09SRSwgYnV0 IHRoYXQgb2YgY291cnNlIGNhbid0IGJlIHdoYXQncyBhY3R1YWxseQ0KICAgIGludGVuZGVkLiAg UGVyaGFwcyBqdXN0IHNheWluZyB0aGF0IHRoZSBiZWhhdmlvciBvZiB0aGUgaW50cm9zcGVjdGlv bg0KICAgIGVuZHBvaW5nIGlzIHNwZWNpZmllZCBpbiBzZWN0aW9uIDUuNyBvZiBbZnJhbWV3b3Jr XSBhbmQgdGhhdCBvZiB0aGUgdG9rZW4NCiAgICBlbmRwb2ludCBpcyBzcGVjaWZpZWQgaW4gc2Vj dGlvbiA1LjYgb2YgW2ZyYW1ld29ya10gd291bGQgc3VmZmljZT8nJw0KDQpGUDogTm8sIHRoaXMg c2VudGVuY2Ugd2FudGVkIHRvIGFkZCB0byB0aGUgcHJldmlvdXMgKOKAnGlmIE9TQ09SRSBpcyB1 c2Vk4oCdKSwgYW5kIGp1c3QgcG9pbnQgdG8gdGhlIGZyYW1ld29ya+KAmXMgc2VjdGlvbiBmb3Ig dGhlIHNwZWNpZmljIGJlaGF2aW91cnMuIFdpbGwgcmVwaHJhc2UuDQogICAgDQogICAgU2VjdGlv biA2DQogICAgDQo4Mi4gICAgICAgbyAgdGhlIGNsaWVudCByZWNlaXZlcyBhIG51bWJlciBvZiA0 LjAxIFVuYXV0aG9yaXplZCByZXNwb25zZXMgdG8NCiAgICAgICAgICBPU0NPUkUgcmVxdWVzdHMg dXNpbmcgdGhlIHNhbWUgc2VjdXJpdHkgY29udGV4dC4gIFRoZSBleGFjdCBudW1iZXINCiAgICAg ICAgICBuZWVkcyB0byBiZSBzcGVjaWZpZWQgYnkgdGhlIGFwcGxpY2F0aW9uLg0KICAgIA0KICAg IElzIHRoaXMgYSBnbG9iYWwgY291bnRlciBvciBkb2VzIGl0IGdldCByZXNldCBieSBhIHN1Y2Nl c3NmdWwgT1NDT1JFDQogICAgcmVzcG9uc2U/DQoNCkZQOiBJIHdvdWxkIHNheSB0aGlzIGdldHMg cmVzZXQgYnkgYSBzdWNjZXNzZnVsIE9TQ09SRSByZXNwb25zZS4gQnV0IHByb2JhYmx5IHRoZSBh cHBsaWNhdGlvbiB3b3VsZCBoYXZlIHRvIGRlZmluZSB0aGF0IGFzIHdlbGwuIERvIHdlIG5lZWQg dG8gYWRkIGFueSB0ZXh0IGFib3V0IHRoaXM/DQogICAgDQo4My4gICAgICAgbyAgdGhlIGNsaWVu dCByZWNlaXZlcyBhIG5ldyBub25jZSBpbiB0aGUgMi4wMSAoQ3JlYXRlZCkgcmVzcG9uc2UNCiAg ICAgICAgICAoc2VlIFNlY3Rpb24gNC4yKSB0byBhIFBPU1QgcmVxdWVzdCB0byB0aGUgYXV0aHot aW5mbyBlbmRwb2ludCwNCiAgICAgICAgICB3aGVuIHJlLXBvc3RpbmcgYSBub24tZXhwaXJlZCB0 b2tlbiBhc3NvY2lhdGVkIHRvIHRoZSBleGlzdGluZw0KICAgICAgICAgIGNvbnRleHQuDQogICAg DQogICAgV2h5IGlzICJub24tZXhwaXJlZCIgc3BlY2lmaWNhbGx5IHJlbGV2YW50Pw0KDQpGUDog YmVjYXVzZSBpZiBpdOKAmXMgZXhwaXJlZCB0aGUgUlMgd2lsbCBub3QgYWNjZXB0IHRoYXQgdG9r ZW4uIFRoaXMgd2FzIGp1c3QgZm9yIGNsYXJpZmljYXRpb24uDQpXaGF0IGFib3V0IGFkZGluZyBh IHBhcmVudGhlc2lzIOKAnChub24tZXhwaXJlZCnigJ0/DQogICAgDQo4NC4gICAgICAgVGhlIFJT IE1VU1QgZGlzY2FyZCB0aGUgY3VycmVudCBzZWN1cml0eSBjb250ZXh0IGFzc29jaWF0ZWQgd2l0 aCBhDQogICAgICAgY2xpZW50IHdoZW46DQogICAgDQogICAgICAgbyAgU2VxdWVuY2UgTnVtYmVy IHNwYWNlIGVuZHMuDQogICAgDQogICAgICAgbyAgQWNjZXNzIHRva2VuIGFzc29jaWF0ZWQgd2l0 aCB0aGUgY29udGV4dCBleHBpcmVzLg0KICAgIA0KICAgIG5pdDogd2Ugc2hvdWxkIG1ha2UgdGhl IGdyYW1tYXIgb2YgdGhlIGxpc3QgZWxlbWVudHMgcGFyYWxsZWwgdG8gdGhlIGNsaWVudCdzDQog ICAgbGlzdCwgc28gInRoZSBTZXF1ZW5jZSBOdW1iZXIgc3BhY2UgZW5kcy4iIGFuZCAidGhlIGFj Y2VzcyB0b2tlbiBhc3NvY2lhdGVkDQogICAgd2l0aCB0aGUgY29udGV4dCBleHBpcmVzIi4NCg0K RlA6IERvbmUgaW4gUFIuDQogICAgDQogICAgU2VjdGlvbiA3DQogICAgDQo4NS4gICAgV2UgdGFs ayBhYm91dCBib3RoIG5vbmNlcyBhcyBuZWVkaW5nIHRvIGJlICJ2ZXJ5IHVubGlrZWx5IHRvIGhh dmUgYmVlbg0KICAgIHByZXZpb3VzbHkgdXNlZCIsIGFuZCBpdCBtaWdodCBiZSB3b3J0aCB0cnlp bmcgdG8gcXVhbnRpZnkgdGhhdCAoZS5nLiwNCiAgICAiY2hhbmNlIG9mIGluYWR2ZXJ0ZW50IGNv bGxpc2lvbiBsZXNzIHRoYW4gMl4tMzIiKS4NCiAgICANCkZQOiBUaGlzIGlzIGhhcmQgdG8gcXVh bnRpZnkgaW4gYSBnZW5lcmFsIGNhc2UuIEJ1dCB3ZSBjYW4gYWRkIHNvbWUgdGV4dCBhYm91dCBh dm9pZGluZyBpbmFkdmVydGVudCBjb2xsaXNpb25zLg0KDQo4Ni4gICAgQXMgYWxsdWRlZCB0byBp biBteSBoaWdoLWxldmVsIHBvaW50LCB3ZSBzaG91bGQgaGF2ZSBtb3JlIGRpc2N1c3Npb24gb2YN CiAgICB0aGUgY29uc2VxdWVuY2VzIG9mIHRoZSBhdXRoei1pbmZvIGV4Y2hhbmdlIGJlaW5nIGNv bXBsZXRlbHkNCiAgICB1bnByb3RlY3RlZC4NCg0KRlA6IExldCdzIGRpc2N1c3MgdGhhdCBpbiB0 aGUgcG9pbnQgYWJvdmUuDQogICAgDQo4Ny4gICAgICAgYSBzZWN1cmUgYmluZGluZyBiZXR3ZWVu IHRoZSByZXF1ZXN0IGFuZCB0aGUgcmVzcG9uc2UocykuICBUaHVzIHRoZQ0KICAgICAgIGJhc2lj IE9TQ09SRSBwcm90b2NvbCBpcyBub3QgaW50ZW5kZWQgZm9yIHVzZSBpbiBwb2ludC10by1tdWx0 aXBvaW50DQogICAgICAgY29tbXVuaWNhdGlvbiAoZS5nLiBtdWx0aWNhc3QsIHB1Ymxpc2gtc3Vi c2NyaWJlKS4gIEltcGxlbWVudGVycyBvZg0KICAgIA0KICAgIG5pdDogY29tbWEgYWZ0ZXIgImUu Zy4iLg0KDQpGUDogRG9uZSBpbiBQUi4NCiAgICANCjg4LiAgICAgICBwcm92b2tlIHJlLXVzZS4g IElmIHRoYXQgaXMgbm90IGd1YXJhbnRlZWQsIG5vZGVzIGFyZSBzdGlsbA0KICAgICAgIHN1c2Nl cHRpYmxlIHRvIHJlLXVzaW5nIEFFQUQgbm9uY2VzIGFuZCBrZXlzLCBpbiBjYXNlIHRoZSBTZWN1 cml0eQ0KICAgICAgIENvbnRleHQgaXMgbG9zdCwgYW5kIG9uLXBhdGggYXR0YWNrZXIgcmVwbGF5 IG1lc3NhZ2VzLg0KICAgIA0KICAgIFRoaXMgdGV4dCBpcyB0YWxraW5nIGFib3V0IEFFQUQgbm9u Y2VzLCBidXQgdGhlIG5vbmNlcyAoYW5kIDY0LWJpdA0KICAgIHJlY29tbWVuZGF0aW9uKSBwcmV2 aW91c2x5IGRpc2N1c3NlZCBhcmUgdGhlIG5vbmNlcyB1c2VkIGluIHRoZSBNYXN0ZXIgU2FsdA0K ICAgIChhbmQgdGh1cyBNYXN0ZXIgU2VjcmV0KSBjYWxjdWxhdGlvbjsgd2UgZG9uJ3QgcmVhbGx5 IHRhbGsgYWJvdXQgQUVBRCBub25jZXMNCiAgICBzcGVjaWZpY2FsbHkgYW55d2hlcmUgaW4gdGhl IGRvY3VtZW50LCBvdGhlciB0aGFuIHRvIHBvaW50IG91dCB0aGUgcmlzayBvZg0KICAgIChub25j ZSwga2V5KSByZXVzZS4gIElJVUMsIHZ1bG5lcmFibGUgbm9kZXMgd291bGQgbmVlZCB0byByZXVz ZSBib3RoIHRoZQ0KICAgIE4xIG9yIE4yIHZhbHVlcyBkZWZpbmVkIGluIHRoaXMgc3BlYyBhcyB3 ZWxsIGFzIHRoZSBPU0NPUkUgcGFydGlhbCBJViBpbg0KICAgIG9yZGVyIHRvIGNvbGxpZGUgdGhl IEFFQUQgKG5vbmNlLCBrZXkpIHBhaXIgKG5vdGluZyB0aGF0IGJvdGgga2V5IGFuZCBjb21tb24N CiAgICBJViBhcmUgaW5mbHVlbmNlZCBieSB0aGUgTWFzdGVyIFNhbHQpLiAgVGhhdCBzYWlkLCBp ZiB0aGUgTjEgZ2VuZXJhdGlvbiBpcw0KICAgIGZsYXdlZCBpdCBzZWVtcyBxdWl0ZSBwbGF1c2li bGUgdGhhdCBQSVYgZ2VuZXJhdGlvbiBpcyBzaW1pbGFybHkgZmxhd2VkLCBzbw0KICAgIHdlIGFy ZSByaWdodCB0byBkb2N1bWVudCB0aGUgY29uY2Vybi4NCiAgICBBbHNvLCB0aGUgZ3JhbW1hciBo ZXJlIGlzIGEgbGl0dGxlIGJpdCB3ZWlyZCwgc28gcGVyaGFwcyBhIHJld29yZGluZyB0bzoNCiAg ICANCiAgICAlICBwcm92b2tlIHJlLXVzZS4gIElmIHRoYXQgaXMgbm90IGd1YXJhbnRlZWQsIG5v ZGVzIGFyZQ0KICAgICUgIHN1c2NlcHRpYmxlIHRvIHJlLXVzZSBvZiBBRUFEIChub25jZXMsIGtl eXMpIHBhaXJzLCBlc3BlY2lhbGx5IHNpbmNlIGFuIG9uLXBhdGgNCiAgICAlICBhdHRhY2tlciBj YW4gY2F1c2UgdGhlIGNsaWVudCB0byB1c2UgYW4gYXJiaXRyYXJ5IG5vbmNlIGZvciBTZWN1cml0 eQ0KICAgICUgIENvbnRleHQgZXN0YWJsaXNobWVudC4gIEV2ZW4gcGFydGlhbCBsb3NzIG9mIFNl Y3VyaXR5IENvbnRleHQgaW5mb3JtYXRpb24NCiAgICAlICBjYW4gYWxsb3cgYW4gb24tcGF0aCBh dHRhY2tlciB0byByZXBsYXkgbWVzc2FnZXMuDQogICAgDQogICAgdGhvdWdoIEknbSBub3QgZW50 aXJlbHkgc3VyZSBJIHVuZGVyc3RhbmQgd2hpY2ggcmVwbGF5IHNjZW5hcmlvcyB5b3UgaGFkIGlu DQogICAgbWluZC4NCiAgICANCkZQOiBJIHRoaW5rIHRoZSBsYXN0IHNlbnRlbmNlIGluIHlvdXIg cmV3b3JkaW5nIGlzIHBhcnRpYWxseSBjaGFuZ2luZyB0aGUgaW50ZW50IG9mIHRoZSBwYXJhZ3Jh cGguIFBhcnRpYWwgbG9zcyBkb2VzIG5vdCBhbGxvdyBhdHRhY2tlciB0byByZXBsYXkgbWVzc2Fn ZXM7IHdoYXQgd2FzIG1lYW50IGJ5IHRoYXQgaXMgdGhhdCwgaWYgdGhlIGNvbnRleHQgaXMgbG9z dCAodGhpbmsgcmVib290IHdpdGhvdXQgdXNlIG9mIHBlcnNpc3RlbnQgbWVtb3J5LCB3aGVyZSBw YXJ0aWFsIElWIGNvdWxkIHJlc2V0IHRvIHByZXZpb3VzbHkgdXNlZCBJVnMsIGFuZCBub2Rl4oCZ cyBub25jZSByZXNldHMgdG8gcHJldmlvdXNseSB1c2VkIG5vbmNlKSBhbmQgYXQgdGhlIHNhbWUg dGltZSB0aGUgYXR0YWNrZXIgcmVwbGF5cyBhbiBvbGQgbWVzc2FnZSAoc28gc2Vjb25kIG5vbmNl IGlzIHByZXZpb3VzbHkgdXNlZCB0b28pLCB0aGF0IGNyZWF0ZXMgdGhlIHByb2JsZW0uIEkgd291 bGQganVzdCByZW1vdmUgdGhlIGxhc3Qgc2VudGVuY2Ugb2YgeW91ciByZXdvcmRlZCBwYXJhZ3Jh cGggYW5kIHdvdWxkIGJlIGZpbmUgd2l0aCB0aGF0Lg0KDQo4OS4gICAgICAgVGhpcyBwcm9maWxl cyByZWNvbW1lbmRzIHRoYXQgdGhlIFJTIG1haW50YWlucyBhIHNpbmdsZSBhY2Nlc3MgdG9rZW4N CiAgICANCiAgICBuaXQ6ICJUaGlzIHByb2ZpbGUiIHNpbmd1bGFyLg0KICAgIA0KRlA6IERvbmUg aW4gUFIuDQoNCjkwLiAgICAgICBBbHNvLCB0b2tlbnMgbWF5IGNvbnRyYWRpY3QgZWFjaCBvdGhl ciB3aGljaCBtYXkgbGVhZCB0aGUgc2VydmVyIHRvDQogICAgICAgZW5mb3JjZSB3cm9uZyBwZXJt aXNzaW9ucy4gIElmIG9uZSBvZiB0aGUgYWNjZXNzIHRva2VucyBleHBpcmVzDQogICAgDQogICAg Q291bGQgeW91IGdpdmUgbWUgYW4gZXhhbXBsZSBvZiB0aGUgY29udHJhZGljdGlvbiBzY2VuYXJp b3M/ICBJIHNlZSB0aGUNCiAgICAiY29tbW9uIiBjYXNlIGFzIGJlaW5nIHJvdWdobHkgIlRva2Vu IFQxIGdpdmVzIGFjY2VzcyB0byB0aGUgc2V0IFggb2YNCiAgICByZXNvdXJjZXMgYW5kIHRva2Vu IFQyIGdpdmVzIGFjY2VzcyB0byBhIHBhcnRpYWxseSBkaXNqb2ludCBzZXQgWSBvZg0KICAgIHJl c291cmNlcyIsIGJ1dCBJIGRvbid0IGtub3cgdGhhdCBzdWNoIGEgc2NlbmFyaW8gd291bGQgYmUg Y29uc2lkZXJlZCBhDQogICAgImNvbmZsaWN0Ii4gIFRvIGdldCBhIGNvbmZsaWN0IEknZCBleHBl Y3QgbW9yZSBsaWtlICJ0b2tlbiBUMSBpbmRpY2F0ZXMgdGhhdA0KICAgIGFjY2VzcyB0byBYIGlz IHRvIGJlIGRlbmllZCwgYnV0IHRva2VuIFQyIGluZGljYXRlcyB0aGF0IGFjY2VzcyB0byBYIGlz IHRvIGJlDQogICAgYWxsb3dlZCIgd2l0aCBzb21lIHNvcnQgb2YgZXhwbGljaXQgbmVnYXRpdmUg QUNMLCBidXQgSSBkb24ndCB0aGluayBPQXV0aA0KICAgIHJlYWxseSBoYXMgYSBjb25jZXB0IG9m IG5lZ2F0aXZlIEFDTC4NCg0KRlA6IE5vLCBJIG1lYW50IHdoYXQgeW91IGRlc2NyaWJlIGFzIHRo ZSBjb21tb24gY2FzZS4gVGhlIGNvbnRyYWRpY3Rpb24gY29taW5nIGZyb20gdGhlIGZhY3QgdGhh dCBvbmUgdG9rZW4gd291bGQgZ2l2ZSBhY2Nlc3MgdG8gYSBzZXQgWCBvZiByZXNvdXJjZSB0aGF0 IHRoZSBvdGhlciB0b2tlbiB3b3VsZCBub3QgZ2l2ZSBhY2Nlc3MgdG8uIEEgc2VydmVyIGltcGxl bWVudGF0aW9uIG1pZ2h0IGNoZWNrIG9ubHkgb25lIHRva2VuLCB3aGljaCBjb3VsZCBsZWFkIHRv IHdyb25nIHBlcm1pc3Npb25zLiBEbyB3ZSBuZWVkIHRvIHNheSBhbnl0aGluZyBlbHNlIGhlcmU/ DQogICAgDQogICAgU2VjdGlvbiA4DQogICAgDQo5MS4gICAgVGhlcmUgbWlnaHQgYmUgYSBmZXcg bW9yZSBwcml2YWN5IGNvbnNpZGVyYXRpb25zIHdvcnRoIG1lbnRpb25pbmc6DQogICAgDQogICAg LSB0aGUgdG9rZW4gaXMgc2VudCBpbiB0aGUgY2xlYXIgdG8gdGhlIGF1dGh6LWluZm8gZW5kcG9p bnQsIHNvIGlmIGEgc2luZ2xlDQogICAgICB0b2tlbiBpcyB1c2VkIHdpdGggbXVsdGlwbGUgYXVk aWVuY2VzIG9yIFJTZXMsIGEgY2xpZW50IHRoYXQgdXNlcyB0aGUgc2FtZQ0KICAgICAgdG9rZW4g ZnJvbSBtdWx0aXBsZSBsb2NhdGlvbnMgY2FuIGJlIHRyYWNrZWQvY29ycmVsYXRlZCBieSB0aGUg YWNjZXNzDQogICAgICB0b2tlbidzIHZhbHVlLg0KDQpGUDogT0sNCg0KICAgIC0gdGhlIG5vbmNl cyBleGNoYW5nZWQgaW4gdGhlIGF1dGh6LWluZm8gZXhjaGFuZ2UgYXJlIGFsc28gc2VudCBpbiB0 aGUgY2xlYXIsDQogICAgICBzbyB1c2luZyByYW5kb20gbm9uY2VzIGlzIGJlc3QgZm9yIHByaXZh Y3kgKGFzIG9wcG9zZWQgdG8sIGUuZy4sIGEgY291bnRlciwNCiAgICAgIHRoYXQgbWlnaHQgbGVh ayBzb21lIGluZm9ybWF0aW9uKS4NCg0KRlA6IE9LDQoNCiAgICAtIHRoZSBpZGVudGlmaWVycyBj bGllbnRJZC9zZXJ2ZXJJZCB0aGF0IGFyZSBjcmVhdGVkL2Fzc2lnbmVkIGZvciB0aGlzDQogICAg ICBwcm90b2NvbCBoYXZlIHNvbWUgcHJpdmFjeSBjb25zaWRlcmF0aW9uczsgdGhleSBvdmVybGFw IGEgbG90IHdpdGggdGhlIGNvcmUNCiAgICAgIE9TQ09SRSBjb25zaWRlcmF0aW9ucyBpbiB0ZXJt cyBvZiB0aGUgcG90ZW50aWFsIHByaXZhY3kgY29uc2VxdWVuY2VzIGJ1dA0KICAgICAgdGhlcmUg bWlnaHQgYmUgYSBsaXR0bGUgbW9yZSB0byBzYXkgYWJvdXQgZ3VpZGVsaW5lcyBmb3IgaG93IHRo ZQ0KICAgICAgaWRlbnRpZmllcnMgYXJlIGdlbmVyYXRlZC4gIElmIEknbSByZWFkaW5nIE9TQ09S RSBjb3JyZWN0bHksIGZvciB0aGUgdXNlcw0KICAgICAgc3BlY2lmaWVkIGluIHRoaXMgZG9jdW1l bnQgb25seSB0aGUgY2xpZW50SWQgd2lsbCBhY3R1YWxseSBnbyBvbiB0aGUgd2lyZT8NCg0KRlA6 IHRoYXTigJlzIHJpZ2h0LCB1bmxlc3MgY2xpZW50IGFuZCBzZXJ2ZXIgc3dhcCByb2xlcywgaW4g d2hpY2ggY2FzZSBhbHNvIHNlcnZlcklkIChhY3RpbmcgYXMgY2xpZW50KSBjb3VsZCBnbyBvbiB0 aGUgd2lyZS4gSSB0aG91Z2h0IE9TQ09SRSBzaG91bGQgaGF2ZSB0aGlzIGNvdmVyZWQuIFdoYXQg YWRkaXRpb25hbCBkZXRhaWxzIGFyZSBtaXNzaW5nIGhlcmU/DQoNCiAgICAtIHNpbWlsYXJseSwg dGhlcmUgbWF5IGJlIGNvbnNpZGVyYXRpb25zIGZvciB0aGUgSUQgY29udGV4dCB2YWx1ZXMuDQoN CkZQOiBzYW1lLCByZWZlcmVuY2luZyBPU0NPUkUgc2hvdWxkIGNvdmVyIGl0LCBubz8NCiAgICAN CiAgICBTZWN0aW9uIDkuMQ0KICAgIA0KOTIuICAgICAgIG8gIFByb2ZpbGUgRGVzY3JpcHRpb246 IFByb2ZpbGUgZm9yIHVzaW5nIE9TQ09SRSB0byBzZWN1cmUNCiAgICAgICAgICBjb21tdW5pY2F0 aW9uIGJldHdlZW4gY29uc3RyYWluZWQgbm9kZXMgdXNpbmcgdGhlIEF1dGhlbnRpY2F0aW9uDQog ICAgICAgICAgYW5kIEF1dGhvcml6YXRpb24gZm9yIENvbnN0cmFpbmVkIEVudmlyb25tZW50cyBm cmFtZXdvcmsuDQogICAgDQogICAgVGhpcyBpcyB0aGUgcmVnaXN0cnkgZm9yIEFDRSBwcm9maWxl czsgInVzaW5nIHRoZSBBdXRoZW50aWNhdGlvbiBhbmQNCiAgICBBdXRob3JpemF0aW9uIGZvciBD b25zdHJhaW5lZCBFbnZpcm9ybm1lbnRzIGZyYW1ld29yayIgZmVlbHMgcmVkdW5kYW50Lg0KICAg IFRoZXJlJ3MgYWxzbyBwZXJoYXBzIHNvbWV0aGluZyB0byBzYXkgYWJvdXQgZGVmaW5pbmcgImNv YXBfb3Njb3JlIiBmb3IgYWxsDQogICAgdGhyZWUgaW50ZXJhY3Rpb24gZmxvd3MgZXZlbiB0aG91 Z2ggdGhlIHByb2NlZHVyZXMgZm9yIHR3byBvZiB0aGUgdGhyZWUgYXJlDQogICAgZXNzZW50aWFs bHkganVzdCAib3V0IG9mIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24iLCB0aG91Z2gg aGF2aW5nDQogICAgKnNvbWUqIGlkZW50aWZpZXIgZm9yICJ1c2UgT1NDT1JFIiBpcyBwcm9iYWJs eSBzdGlsbCB1c2VmdWwuDQogICAgDQpGUDogT2ssIHdlIGNhbiByZW1vdmUgdGhlIGxhc3QgcGFy dC4gQWJvdXQgdGhlIGludGVyYWN0aW9uIGZsb3dzIGJldHdlZW4gbm9kZXMsIEkgYW0gbm90IHN1 cmUgd2hhdCB5b3UgbWVhbiwgYXMgYnkgZm9sbG93aW5nIGRlZmluaXRpb24gaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYWNlLW9hdXRoLWF1dGh6LTMxI3NlY3Rpb24tNS42 LjQuMyBpdCBpcyBub3QgbWFuZGF0b3J5IGZvciBhIHByb2ZpbGUgdG8gc3BlY2lmeSBDLUFTIGFu ZCBSUy1BUywgdGhvc2UgZmxvd3MgY2FuIGJlIG91dCBvZiBzY29wZS4gQW0gSSBtaXNzaW5nIHNv bWV0aGluZz8NCg0KICAgIFNlY3Rpb24gOS4yDQogICAgDQo5My4gICAgICAgbmFtZSAgVGhlIEpT T04gbmFtZSByZXF1ZXN0ZWQgKGUuZy4sICJtcyIpLiAgQmVjYXVzZSBhIGNvcmUgZ29hbCBvZg0K ICAgICAgICAgIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyBmb3IgdGhlIHJlc3VsdGluZyByZXByZXNl bnRhdGlvbnMgdG8gYmUNCiAgICAgICAgICBjb21wYWN0LCBpdCBpcyBSRUNPTU1FTkRFRCB0aGF0 IHRoZSBuYW1lIGJlIHNob3J0LiAgVGhpcyBuYW1lIGlzDQogICAgICAgICAgY2FzZSBzZW5zaXRp dmUuICBOYW1lcyBtYXkgbm90IG1hdGNoIG90aGVyIHJlZ2lzdGVyZWQgbmFtZXMgaW4gYQ0KICAg ICAgICAgIGNhc2UtaW5zZW5zaXRpdmUgbWFubmVyIHVubGVzcyB0aGUgRGVzaWduYXRlZCBFeHBl cnRzIHN0YXRlIHRoYXQNCiAgICAgICAgICB0aGVyZSBpcyBhIGNvbXBlbGxpbmcgcmVhc29uIHRv IGFsbG93IGFuIGV4Y2VwdGlvbi4gIFRoZSBuYW1lIGlzDQogICAgDQogICAgbml0OiBJJ2Qgc3Vn Z2VzdCBzL3N0YXRlL2RldGVybWluZS8NCg0KRlA6IERvbmUgaW4gUFINCiAgICANCjk0LiAgICAg ICBDQk9SIGxhYmVsICBUaGUgdmFsdWUgdG8gYmUgdXNlZCB0byBpZGVudGlmeSB0aGlzIGFsZ29y aXRobS4gIEtleSBtYXANCiAgICAgICAgICBsYWJlbHMgTVVTVCBiZSB1bmlxdWUuICBUaGUgbGFi ZWwgY2FuIGJlIGEgcG9zaXRpdmUgaW50ZWdlciwgYQ0KICAgIA0KICAgIG5pdDogcy9LZXkgbWFw L01hcCBrZXkvDQoNCkZQOiBEb25lIGluIFBSDQogICAgDQo5NS4gICAgICAgICAgbmVnYXRpdmUg aW50ZWdlciBvciBhIHN0cmluZy4gIEludGVnZXIgdmFsdWVzIGJldHdlZW4gMCBhbmQgMjU1DQog ICAgICAgICAgYW5kIHN0cmluZ3Mgb2YgbGVuZ3RoIDEgYXJlIGRlc2lnbmF0ZWQgYXMgU3RhbmRh cmRzIFRyYWNrIERvY3VtZW50DQogICAgICAgICAgcmVxdWlyZWQuICBJbnRlZ2VyIHZhbHVlcyBm cm9tIDI1NiB0byA2NTUzNSBhbmQgc3RyaW5ncyBvZiBsZW5ndGgNCiAgICAgICAgICAyIGFyZSBk ZXNpZ25hdGVkIGFzIFNwZWNpZmljYXRpb24gUmVxdWlyZWQuICBJbnRlZ2VyIHZhbHVlcyBvZg0K ICAgICAgICAgIGdyZWF0ZXIgdGhhbiA2NTUzNSBhbmQgc3RyaW5ncyBvZiBsZW5ndGggZ3JlYXRl ciB0aGFuIDIgYXJlDQogICAgICAgICAgZGVzaWduYXRlZCBhcyBleHBlcnQgcmV2aWV3LiAgSW50 ZWdlciB2YWx1ZXMgbGVzcyB0aGFuIC02NTUzNiBhcmUNCiAgICAgICAgICBtYXJrZWQgYXMgcHJp dmF0ZSB1c2UuDQogICAgDQogICAgU28gdXNlIG9mIG5lZ2F0aXZlIGludGVnZXJzIGZyb20gLTY1 NTM1IHRvIC0xIGFuZCBwb3NpdGl2ZSBpbnRlZ2VycyBncmVhdGVyDQogICAgdGhhbiBvciBlcXVh bCB0byA2NTUzNiBpcyBub3QgZGVmaW5lZD8NCg0KRlA6IE9LIFJpZ2h0IHdlIG1pc3NlZCBpdC4g V2Ugd2lsbCBmaXggaXQuDQogICAgDQogICAgSSdkIGFsc28gY29uc2lkZXIgbGlzdGluZyBbSS1E LmlldGYtY29yZS1vYmplY3Qtc2VjdXJpdHldIGFzIGFuDQogICAgYWRkaXRpb25hbCByZWZlcmVu Y2UgZm9yIHRoZSBpbml0aWFsIGVudHJpZXMsIHNpbmNlIHRoYXQgc3BlY2lmaWVzIHRoZQ0KICAg IGFjdHVhbCBzZW1hbnRpY3Mgb2YgdGhlIGZpZWxkcyBpbiBxdWVzdGlvbi4NCg0KRlA6IE9LDQog ICAgDQogICAgU2VjdGlvbiA5LjMNCiAgICANCjk2LiAgICAiT1NDT1JFX1NlY3VyaXR5X0NvbnRl eHQiIGZlZWxzIGxpa2UgYSBzb21ld2hhdCBsb25nIG5hbWUgaW4gbGlnaHQgb2YgdGhlDQogICAg cHJldmlvdXMgY29tbWVudGFyeSBhYm91dCBzaG9ydGVyIG5hbWVzIGJlaW5nIHByZWZlcnJlZC4g OikNCiAgICANCkZQOiBUeXBpY2FsbHkgdGhpcyB3aG9sZSBuYW1lIHNob3VsZCBub3QgYmUgc2Vu dCB3aGVuIENCT1IgaXMgdXNlZCAoc28gaW4gY29uc3RyYWluZWQgZW52aXJvbm1lbnRzKS4gQnV0 IHdl4oCZbGwgc2hvcnRlbiBpdCwgd2hhdCBhYm91dCAiU2VjX0N0eCI/DQoNCjk3LiAgICAgICBv ICBDb25maXJtYXRpb24gTWV0aG9kIERlc2NyaXB0aW9uOiBPU0NPUkVfU2VjdXJpdHlfQ29udGV4 dCBjYXJyeWluZw0KICAgICAgICAgIHRoZSBPU0NPUkUgU2VjdXJpdHkgQ29udGV4dCBwYXJhbWV0 ZXJzDQogICAgDQogICAgSSdkIHN1Z2dlc3QgcmV3b3JkaW5nIHRoZSBkZXNjcmlwdGlvbiB0byAi cGFyYW1ldGVycyBmb3IgdXNpbmcgT1NDT1JFDQogICAgcGVyLW1lc3NhZ2Ugc2VjdXJpdHkgd2l0 aCBpbXBsaWNpdCBrZXkgY29uZmlybWF0aW9uIg0KICAgIA0KRlA6IE9rLCBzdGlsbCB3b3VsZCBs aWtlIHRvIGtlZXAgT1NDT1JFX1NlY3VyaXR5X0NvbnRleHQgKG9yIHdoYXRldmVyIHRoZSBzdHJ1 Y3R1cmUgd2lsbCBiZSBjYWxsZWQpIHNvbWV3aGVyZSBpbiB0aGUgZGVzY3JpcHRpb24uDQoNCiAg ICBTZWN0aW9uIDkuNA0KICAgIA0KOTguDQoNCiAgICBbc2FtZSBzdWdnZXN0ZWQgcmV3b3JkaW5n XQ0KDQpGUDogT0sNCiAgICANCiAgICBTZWN0aW9uIDkuNQ0KICAgIA0KOTkuICAgICBUaGFuayB5 b3UgZm9yIGluZGljYXRpbmcgaW4gd2hpY2ggZGlyZWN0aW9uIHRoZSB2YXJpb3VzIGNvbnNpZGVy YXRpb25zIHNob3VsZA0KICAgIHN3YXkgdGhlIGV4cGVydHMnIGRlY2lzaW9ucywgYXMgb3Bwb3Nl ZCB0byBqdXN0IHdoYXQgdGhlIGV4cGVydHMgc2hvdWxkDQogICAgY29uc2lkZXIuIDopDQoNCkZQ OiBnb29kLg0KICAgIA0KMTAwLiAgICAgICBUaGUgSUFOQSByZWdpc3RyeSBlc3RhYmxpc2hlZCBp biB0aGlzIGRvY3VtZW50IGlzIGRlZmluZWQgYXMgZXhwZXJ0DQogICAgICAgcmV2aWV3LiAgVGhp cyBzZWN0aW9uIGdpdmVzIHNvbWUgZ2VuZXJhbCBndWlkZWxpbmVzIGZvciB3aGF0IHRoZQ0KICAg IA0KICAgIG5pdDogSSBzdWdnZXN0ICJkZWZpbmVkIHRvIHVzZSB0aGUgRXhwZXJ0IFJldmlldyBy ZWdpc3RyYXRpb24gcG9saWN5Ii4NCg0KRlA6IERvbmUgaW4gUFINCiAgICANCjEwMSAgICAgICAg ICBUaGUgem9uZXMgdGFnZ2VkIGFzIHByaXZhdGUgdXNlIGFyZSBpbnRlbmRlZCBmb3IgdGVzdGlu ZyBwdXJwb3Nlcw0KICAgICAgICAgIGFuZCBjbG9zZWQgZW52aXJvbm1lbnRzLCBjb2RlIHBvaW50 cyBpbiBvdGhlciByYW5nZXMgc2hvdWxkIG5vdCBiZQ0KICAgICAgICAgIGFzc2lnbmVkIGZvciB0 ZXN0aW5nLg0KICAgIA0KICAgIG5pdDogY29tbWEgc3BsaWNlDQoNCkZQOiBUSUwgY29tbWUgc3Bs aWNlcy4gRG9uZSBpbiBQUi4NCiAgICANCjEwMi4gICAgICAgbyAgU3BlY2lmaWNhdGlvbnMgYXJl IHJlcXVpcmVkIGZvciB0aGUgc3RhbmRhcmRzIHRyYWNrIHJhbmdlIG9mIHBvaW50DQogICAgICAg ICAgYXNzaWdubWVudC4gIFNwZWNpZmljYXRpb25zIHNob3VsZCBleGlzdCBmb3Igc3BlY2lmaWNh dGlvbg0KICAgICAgICAgIHJlcXVpcmVkIHJhbmdlcywgYnV0IGVhcmx5IGFzc2lnbm1lbnQgYmVm b3JlIGEgc3BlY2lmaWNhdGlvbiBpcw0KICAgICAgICAgIGF2YWlsYWJsZSBpcyBjb25zaWRlcmVk IHRvIGJlIHBlcm1pc3NpYmxlLiAgU3BlY2lmaWNhdGlvbnMgYXJlDQogICAgDQogICAgc2lkZSBu b3RlOiB0aGlzIGlzIGEgbGl0dGxlIGF3a3dhcmQsIGFzIFJGQyA3MTIwIGZvcm1hbGx5IGRvZXMg bm90IGFsbG93DQogICAgImVhcmx5IGFsbG9jYXRpb25zIiBmb3IgdGhlICJFeHBlcnQgUmV2aWV3 IiBwb2xpY3ksIHNvIHRoZXJlIGlzIG5vdCBhIGZvcm1hbA0KICAgIHByb2NlZHVyZSBpbiBwbGFj ZSB0byByZXZpZXcgYW5kIGV4cGlyZSBlYXJseSBhbGxvY2F0aW9ucyB0aGF0IGVuZCB1cCBub3QN CiAgICBiZWluZyBuZWVkZWQuICBJdCBtaWdodCBiZSB3b3J0aCBzb21ldGhpbmcgdG8gY2hhdCB3 aXRoIHRoZSBJQU5BIHRhYmxlIGFib3V0DQogICAgaW4gVmFuY291dmVyLg0KICAgIA0KRlA6IFN1 cmUsIHdlIHdpbGwgY2hlY2sgd2l0aCBJQU5BLiBXZSBnb3QgaW5zcGlyZWQgYnkgKHJlYWQgc2hh bWVsZXNzbHkgc3RvbGUgZnJvbSkgQ09TRSBoZXJlLg0KDQogICAgU2VjdGlvbiAxMC4yDQogICAg DQoxMDMuICAgIFdlIG1pZ2h0IGdldCBzb21lIHN0aWNrbGVycyBhc2tpbmcgZm9yIHRoZSB0ZXJt aW5vbG9neSByZWZlcmVuY2VzIHRvIGJlIG1hZGUNCiAgICBub3JtYXRpdmUsIGJ1dCBJJ20gbm90 IGNvbmNlcm5lZCBhYm91dCBpdCBvbmUgd2F5IG9yIHRoZSBvdGhlciBmb3Igbm93Lg0KICAgIA0K RlA6IE9LLCB3aWxsIGtlZXAgaW4gbWluZC4NCg0KICAgIEFwcGVuZGl4IEENCiAgICANCjEwNC4g ICAgVGhhbmsgeW91IGZvciBhc3NlbWJsaW5nIHRoaXMgaW4gbGlzdCBmb3JtIGZvciBtZS4NCiAg ICBEbyB3ZSBleHBlY3QgdG8ga2VlcCB0aGlzIGNvbnRlbnQgaW4gdGhlIGZpbmFsIFJGQz8gIElm IHdlIGRvLCB3ZSBzaG91bGQNCiAgICByZXN5bmNocm9uaXplIHRvIHRoZSBjdXJyZW50IGxpc3Qg aW4gQXBwZW5kaXggQyBvZiB0aGUgZnJhbWV3b3JrIDopDQoNCkZQOiBEZWZpbml0ZWx5IHNob3Vs ZCByZXN5bmNocm9uaXplLiBZZXMgSeKAmWQgbGlrZSB0aGlzIGNvbnRlbnQgdG8gc3RheS4NCiAg ICANCjEwNS4gICAgICAgbyAgaG93L2lmIHRoZSBhdXRoei1pbmZvIGVuZHBvaW50IGlzIHByb3Rl Y3RlZDogU2VjdXJpdHkgcHJvdG9jb2wNCiAgICAgICAgICBhYm92ZQ0KICAgIA0KICAgIEkgdGhv dWdodCBhdXRoei1pbmZvIHdhcyBmdWxseSB1bnByb3RlY3RlZCwgcGVyIFNlY3Rpb24gNC4xJ3Mg IlRoZSBhdXRoei1pbmZvDQogICAgZW5kcG9pbnQgaXMgbm90IHByb3RlY3RlZCwgbm9yIGFyZSB0 aGUgcmVzcG9uc2VzIGZyb20gdGhpcyByZXNvdXJjZS4iDQoNCkZQOiBPSywgd2lsbCBmaXguDQog ICAgDQogICAgVGhhbmtzLA0KICAgIA0KICAgIEJlbg0KICAgIA0KICAgIF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgQWNlIG1haWxpbmcgbGlzdA0K ICAgIEFjZUBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vYWNlDQogICAgDQoNCg== From nobody Wed Jan 29 06:54:19 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5AF3120128; Wed, 29 Jan 2020 06:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBqgXY9yJvxl; Wed, 29 Jan 2020 06:54:12 -0800 (PST) Received: from mail-vs1-f54.google.com (mail-vs1-f54.google.com [209.85.217.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 949CA120118; Wed, 29 Jan 2020 06:54:12 -0800 (PST) Received: by mail-vs1-f54.google.com with SMTP id g15so10604014vsf.1; Wed, 29 Jan 2020 06:54:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4rLjBAf/U5NzaVKZ+vOuZu3/esY0xcdv+uQfDq5Ixpk=; b=QUZVdmXpMu85mdGrOiFXNd9H9Pkrs0PU6Pw0/9KLdXs5R0qq8nuZn6r6rygZApS/sL MTrgnCg8sOUUInuaTsd5CXxZM95pJ4qdqJELgQecrVAerjO82SY4Dm+thUO+HzjFc0rf J9R9e1EBsa0K8tPmfjr8UaarrHQ+eq1nV8oybbq+5q2drJWxrN6d/mUeQKa+6GZ42Thz XUtwMF/sql2ZEHdzmkDautGpskPI8Ol/jNptZMu9nI5oOlyiHaxtBztP8X2fvrTLUuzI ddfsgO0FoLiKnrq171nY30LnlrhsLtAK1FoARvMix7Dj6+7hoYiMgbz/4NG9VsuvN54V j2iw== X-Gm-Message-State: APjAAAVI3bFQsnYU8o7TFOzNZXTTVCyK7TbbuzPEZmBGuge5AbyzN0LK Tk3n9vFOSzYAw4qNDlvBn9sixMZoqKAFm5E67KhR4Mac X-Google-Smtp-Source: APXvYqzbiIDWiBJUHPakhfBKiLKWf/OMUKQXZhS1ZrERvlGXNL/P0B/MKjpzM3ntSBj5qSEhOknCNNVQpZqjamnAxls= X-Received: by 2002:a67:b309:: with SMTP id a9mr16802759vsm.97.1580309651136; Wed, 29 Jan 2020 06:54:11 -0800 (PST) MIME-Version: 1.0 References: <007401d5c0f3$6e80d320$4b827960$@augustcellars.com> <012301d5cda8$a5c74f00$f155ed00$@augustcellars.com> In-Reply-To: From: Daniel Migault Date: Wed, 29 Jan 2020 09:53:59 -0500 Message-ID: To: Cigdem Sengul Cc: Daniel Migault , draft-ietf-ace-mqtt-tls-profile@ietf.org, Jim Schaad , Ace Wg Content-Type: multipart/alternative; boundary="00000000000064253a059d48834f" Archived-At: Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-03 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 14:54:18 -0000 --00000000000064253a059d48834f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the comments, please see my responses. I have not answered comments I had nothing to add in order to ease the readability of the thread. That said, I thank you for addressing them. In my opinion, there are a few comments, that needs the WG to state how to address those, and I hope the interim meeting will help. My expectation is that the next version will need to reviewed by a wider audience in the WG so the draft can be moved forward. Yours, Daniel On Wed, Jan 29, 2020 at 7:10 AM Cigdem Sengul wrote: > Thank you for your review Daniel. > Comments inside. > > On Tue, Jan 21, 2020 at 6:23 PM Daniel Migault 40ericsson.com@dmarc.ietf.org> wrote: > >> >> In this document, topics, more specifically, Topic Names, are treated >> as resources. The Clients are assumed to have identified the >> publish/subscribe topics of interest out-of-band (topic discovery is >> not a feature of the MQTT protocol). A resource owner can pre- >> configure policies at the AS that give Clients publish or subscribe >> permissions to different topics. >> >> AS should be expanded. As we introduce the ACE terminology, it >> might be >> good to specify if "resource" terminology is used related to RS. I am no= t >> entirely sure... but if that is the case, it might be good to specify th= at >> these resources are hosted on a Resource Server. >> >> Though this is a very minor issue, there are multiple double >> spaces. >> > > [CS] AS - Fixed. > For RS related comment, added to the previous paragraph: "The MQTT Broker= , > which acts as the Resource Server (RS), is responsible > distributing the messages published by the publishers to their > subscribers. > Blank spaces: Noted, will take care of them in the next version. > > >> Clients use an access token, bound to a proof-of-possession (PoP) key >> to >> authorize with the MQTT Broker their connection and publish/ subscribe >> permissions to topics. >> >> Though I am an not english native, I have difficulties to parse "t= o >> authorize with the MQTT Broker..." This is what I understand from the >> draft: >> The permission to publish/suscbribe topics on a given MQTT Broker are >> defined >> by an access token, bound to a proof-of-possession (PoP) key. The token >> is >> provided by the AS and used by the Client's to access the RS. >> > > [CS] OK. Changed to "Clients prove their permission to publish/subscribe > to topics hosted on an MQTT broker using an access token, bound to a > proof-of-possession (PoP) key." > Is this more clear. > >> >> In the context of this ACE profile, the Broker acts as >> the Resource Server (RS). In the rest of the document the terms "RS" an= d >> "Broker" are used interchangeably. This document describes how to >> authorise >> the following exchanges between the Clients and the Broker. >> >> How to authorize... The wording sounds to me a bit strange though = I >> would >> not pretend to have a better wording either, wouldn't associated >> permission >> more in line with the ACE framework ? >> > > [CS] Fixed authorize. Kept the rest the same.... > > > >> >> o Connection requests from the Clients to the Broker >> >> o Publish requests from the Clients to the Broker, and from the >> Broker to the Clients >> >> o Subscribe requests from Clients to the Broker >> >> This document does not protect the contents of the PUBLISH message >> from the Broker, and hence, the content of the the PUBLISH message is >> >> the the >> > > [CS] Fixed. > >> >> >> Sengul, et al. Expires June 22, 2020 [Page 3] >> >> Internet-Draft MQTT-TLS profile of ACE December 2019 >> >> >> not signed or encrypted separately for the subscribers. This >> >> >> It is the first time the document mentions PUBLISH. It would worth maybe >> to >> specify it is an MQTT message. >> >> I am wondering if encrypted stands for the opposite of not signed. If so= , >> a >> document may be signed but not encrypted. I also understand that the >> security >> is performed by TLS or similar mechanism. If that is correct, it might b= e >> clarifying to mention this is what we have in mind. It is also unclear >> why we >> introduce subscribers and not Clients. Are we excluding intentionally th= e >> publishers? >> >> Maybe wording around: the PUBLISH message is unprotected or protected >> via TLS (or equivalent mechanisms) for each Client's session. . >> >> What is unclear to me is what the "content" of the PUBLISH message >> represents. >> If that is the data associated to the topic. I would have expected >> authentication being performed by a signature mechanism and the signatur= e >> being >> generated by the content owner, that is (I expect) the publisher. I thin= k >> that >> data protection is out-of scope as well as MQTT based mechanisms as MQTT >> recommends TLS. >> >> >> >> [CS] Preceded the sentence with "Clients use MQTT PUBLISH message to > publish to a topic." > > What I meant was protecting the payload from the Broker. At the moment, > the broker is the end of TLS sessions for clients. > So, the Broker does see all the payloads -> if we would like to introduce > "confidential topics", which is the pub-sub document Francesca is working > on, > then the payload needs to be encrypted. Publishers do not sign the > payload either. > > Not excluding publishers really, it is just that the subscribers are the > recipients who would need to check the signature, decrypt if things were > protected. > Reworded as: "The document does not protect the payload of the PUBLISH > message from the Broker, and hence, the payload is not signed or encrypte= d > specifically for subscribers." > > > >> >> functionality may be implemented using the proposal outlined in the >> CoAP Pub-Sub Profile [I-D.palombini-ace-coap-pubsub-profile]. >> >> >> To provide communication confidentiality and RS authentication, TLS >> is used and TLS 1.3 is RECOMMENDED. This document makes the same >> assumptions as the Section 4 of the ACE framework >> [I-D.ietf-ace-oauth-authz] regarding Client and RS registration with >> the AS and setting up keying material. >> >> Is registration appropriated for the RS to the AS? >> > > [CS] I am not sure I understand the question. > This was referring to " It is also assumed that the RS has been registere= d > with the AS, > potentially in a similar way as the client has been registered with > the AS." in Section 4 of draft-ietf-ace-oauth-authz. >> >> >> I think. I was wondering whether it is common to consider registration for RS, as I probably read subscription rather then registration. I think that is fine. Registration is performed to the Broker to receive topics (Client) or to publish topics (RS). > While the Client-Broker >> exchanges are only over MQTT, the required Client-AS and RS-AS >> interactions are described for HTTPS-based communication, using >> 'application/ace+json' content type, and unless otherwise specified, >> using JSON encoding. The token may be a reference, or JSON Web Token >> (JWT). For JWT tokens, this document follows RFC 7800 [RFC7800] for >> PoP semantics for JWTs. >> >> For my own understanding I would like to check if reference stands >> for >> reference to an access token or something else. >> >> > [CS] This is what the draft-ietf-ace-oauth-authz says in Section 3.1, > page 9: "The token is either a simple reference, or a structured > information object." > > I agree this is in draft-ietf-ace-oauth-authz, but it is still unclear to me what the reference can be. It is an ID privately agreed between the parties, an URL,... > The Client-AS and RS-AS may also be other >> than HTTPS e.g., CoAP or MQTT. >> >> I suspect some words are missing. Maybe "may also use other >> transport >> protocol to carry the JWT.<.mglt> >> > > [CS] Corrected to: "The Client-AS and RS-AS MAY also use protocols other > than HTTP e.g., CoAP or MQTT." > >> >> 1.2. ACE-Related Terminology >> >> The terminology for entities in the architecture is defined in OAuth >> 2.0 RFC 6749 [RFC6749] such as "Client" (C), "Resource Server" (RS) >> and "Authorization Server" (AS). >> >> The term "Resource" is used to refer to an MQTT Topic Name, which is >> defined in Section 1.3.. Hence, the "Resource Owner" is any entity >> that can authoritatively speak for the topic. >> >> The introduction is using "resource", I propose the introduction >> text is >> coherent with the Terminology used latter in the document. >> > > [CS] Changed to "resource". > > >> >> 1.3. MQTT-Related Terminology >> >> The document describes message exchanges as MQTT protocol >> interactions. The Clients are MQTT Clients, which connect to the >> Broker to publish and subscribe to Application Messages, labeled with >> their topics. For additional information, please refer to the MQTT >> v5.0 - the OASIS Standard [MQTT-OASIS-Standard-v5] or the MQTT v3.1.1 >> - the OASIS Standard [MQTT-OASIS-Standard]. >> >> MQTTS >> Secured transport profile of MQTT. MQTTS runs over TLS. >> >> I am wondering how appropriated it is to have sentence without >> verb. I >> probably think it is safer to use verb. >> > > [CS] In other IETF drafts, I typically see a definition without a verb. > correct, I cannot figure out what bothered me while reading the definitions. Just go through them to check they are fine, while updating the draft and I will be ok, with what you have. > > e..g, > QUIC: The transport protocol described by this document. > > >> >> Broker >> The Server in MQTT. It acts as an intermediary between the >> Clients that publishes Application Messages, and the Clients >> that made Subscriptions. The Broker acts as the Resource >> Server for the Clients. >> >> Similar comment as before, there seems to have a missing verb. >> While >> Broker is defined, Client is not defined as a special term but instead i= n >> the >> introduction of the section. I am wondering if that would not be cleaner >> to >> have Client also be defined. I am also wondering if Clients cannot be >> designated as subscriber/publisher. Note this is a question I am >> wondering, and >> I do not think a specific terminology would be needed. Instead, I would >> simply >> suggest, that Clients includes subscribers and publishers as these terms >> are >> used later. >> > > [CS] Checking some RFCs, I see it is very common to use sentences like > below. > Have the rules of how to write terminology changed? > > sentence or not does not seem relevant. you are correct. > Added: > Client: A device or program that uses MQTT. (similar to MQTT > descriptions). > > It's actually important not to designate clients as publisher/subscriber. > A client should be able to get permissions to subscribe to x, and publish > to y. > Assume a client has the role of sending out a summary of all published > messages. > It should be able to both publish and subscribe. > > > Thanks for the clarification. That is useful to me. If you think that coudl be usefull to be added to the definition, feel free to add it. > >> Subscription >> A subscription comprises a Topic Filter and a maximum Quality >> of Service (QoS). >> >> It might be relevant to specify that subscriptions are associated >> to one >> session. >> >> [CS} Sure. Added "A subscription is associated with a single session" at > the end. > > > >> Topic Filter >> An expression that indicates interest in one or more Topic >> Names. Topic Filters may include wildcards. >> >> MQTT sends various control messages across a network connection. The >> following is not an exhaustive list and the control packets that are >> not relevant for authorization are not explained. These include, for >> instance, the PUBREL and PUBCOMP packets used in the 4-step handshake >> required for the QoS level 2. >> >> As a general comment, I would recommend to have the same definitio= n >> as >> those provided by MQTTv5. We could clearly mention these are from MQTTv5 >> and >> are repeated here for the document to self contained. There is probably = a >> balance to find to introduce terms that are not used in this document, s= o >> some >> definitions may be partial using [....]. This is mostly a suggestion. >> >> > > [CS] We actually mostly do that anyway. They are just more concise. > I agree there are not major differences, though it might be safer to be as close as possible. > > >> CONNECT >> >> >> >> >> Sengul, et al. Expires June 22, 2020 [Page 5] >> >> Internet-Draft MQTT-TLS profile of ACE December 2019 >> >> >> Client request to connect to the Broker. After a network >> connection is established, this is the first packet sent by a >> Client. >> >> I understand that network connection means the layers below MQTT. = I >> thing >> this is confusing and would suggest to maybe remove "After a network >> connection >> is established," >> > > [CS] OK. But, if we are following the advice of sticking with MQTT spec > for definitions, here is what the original says: > "After a Network Connection is established by a Client to a Server, the > first packet sent from the Client to the Server MUST be a CONNECT packet"= . > >> >> My personal comparison - and I do not mean I am representative - is that the later is clearer. Possible reasons are that the definition in the draft defines CONNECT as a MQTT connect request which seems to me at least some how circular as connection at MQTT layer is not defined. The following sentence introduces network connection, and raised - at least to me - some questions whether the connection was related to MQTT or underlay network settings. It is also confusing to discuss MQTT, network layers and MQTT. I agree differences are in the details, but I would be inclined to take advantage of this work already done. >> SUBSCRIBE >> The Client subscribe request. >> >> I would suggest to have similar wording for PUBLISH as for >> SUBSCRIBE. >> > > [CS] Changed to: "Subscribe request sent from a Client". > > >> >> 2. Authorizing Connection Requests >> >> This section specifies how Client connections are authorized by the >> MQTT Broker.Figure 1 shows the basic protocol flow during connection >> set-up.The token request and response use the /token endpoint at the >> >> I suspect "/" should not be here and that url path is not >> intended. >> >> > [CS] Fixed. > > >> [...] >> >> 2.2.1.. Client-Server Authentication over TLS and MQTT >> >> The Client and the Broker MUST perform mutual authentication. >> >> If I am correct this is also correct for the C-AS. >> > [CS] Yes, added to the previous section. > Actually: According to draft-ietf-ace-oauth-authz: It is also REQUIRED > that the > communicating endpoints perform mutual authentication. > Should it be repeated in the profile as well? > > I would suggest yes, otherwise we wonder while the profile only provide one part of it. > > >> The >> Client MAY authenticate to the Broker over MQTT or TLS. >> >> My understanding of the sentence above is that the Client MAY >> authenticate. Unless I am missing something, I would rather see MUST >> instead. >> > > [CS]OK. The previous sentence say the Client MUST authenticate. > It may use either MQTT or TLS to authenticate. > Still, I changed the sentence to: > "Client MUST authenticate to the Broker either over MQTT or TLS". > > The difference is that we do limit the mechanisms used to authenticate. > > >> For MQTT, >> the options are "None" and "ace". For TLS, the options are "Anon" >> for anonynous client, and "Known(RPK/PSK)" for Raw Public Keys (RPK) >> and Pre-Shared Keys (PSK), respectively. Combined, the Client >> authentication takes the following options: >> >> o "TLS:Anon-MQTT:None": This option is used only for the topics that >> do not require authorization, including the "authz-info" topic. >> Publishing to the "authz-info" topic is described in >> Section 2.2.2. >> >> It is a bit unseal to describe unauthenticated channel as mutually >> authenticated. >> > > [CS] Himmm, not sure how to deal with this. This is the first step to the > Mutual authentication. > I can take this out describe separately. And then have only 3 options for > mutual authentication. > Any thoughts? > > I have no strong opinion. The simplest way seems maybe to point out this is mentioned as a first step to perform the mutual authentication. I am open to any other ways to solve this. > >> o "TLS:Anon-MQTT:ace": The token is transported inside the CONNECT >> message, >> and MUST be validated using one of the methods described in Section 2.2.= 2. >> This option also supports a tokenless connection request for AS discover= y. >> >> o "TLS:Known(RPK/PSK)-MQTT:none": For the RPK, the token MUST have >> been published to the "authz-info" topic. For the PSK, the token >> MAY be, alternatively, provided in the "psk_identity". The TLS >> session set-up is as described in DTLS profile for ACE >> [I-D.ietf-ace-dtls-authorize]. >> >> Just to me sure I understand it properly. In this case the RPK or >> PSK is >> the one contained into the token. DTLS authenticate the TLS client via a >> CertificateRequest. Other information related to the topic are performed >> by the >> MQTT. In order to perform perform the TLS authentication, the token with >> the >> existing key needs to be found. The Broker upon receiving a CONNECT need= s >> to >> keep track of the used token. >> > > [CS] We use TLS - give the DTLS profile as an example of the set-up for > ACE. > Yes: The token is validated, the client is authenticated, a secure TLS > channel with them using the info in the token. > The topic authorisation happens when the client tries to publish or > subscribe. > > >> >> o "TLS:Known(RPK/PSK)-MQTT:ace": This option SHOULD NOT be chosen. >> In any case, the token transported in the CONNECT overwrites any >> permissions passed during the TLS authentication. >> >> My understanding is that the same access token would be used. >> Collision >> would occurs when different access token would be used. However, when >> authentication is performed using DTLS, the Broker, as I would understan= d >> it, >> keeps track of the used token, which should avoid the overwriting >> rules. >> > > [CS] This statement was in case two different tokens were used, the last > valid token overwrites the former. > i.e., u can not add to your permissions - there is no union. > > I have the impression that the requirements is to ensure one token is being used when more token are available. The document provides one way to do, but does not leave room to other mechanisms or implementation. I am wondering if that is something we want or if I am missing something. > >> It is RECOMMENDED that the Client follows TLS:Anon-MQTT:ace. >> >> The Broker MUST be authenticated during the TLS handshake. If the >> Client authentication uses TLS:Known(RPK/PSK), then the Broker is >> authenticated using the respective method. >> >> I understand that when the server is authenticated using RPK, the >> server >> needs to be authenticated using RPK, but it is unclear why standard WPKI >> would >> not work. I understand that for PSK the same method can be used, though. >> >> >> [CS] The language around TLS may have gotten more constrained because I > wanted to follow roughly > what DTLS profile for ACE says... > Though I do not have specific experience with WPKI. > > needs to be clarified by the WG. > > 2.2.2. authz-info: The Authorization Information Topic >> >> >> The Broker stores and indexes all tokens received to this topic in >> its key store similar to DTLS profile for ACE >> [I-D.ietf-ace-dtls-authorize]. This profile follows the >> recommendation of Section 5.8.1 of ACE framework >> [I-D.ietf-ace-oauth-authz], and expects that RS stores only one token >> per proof-of-possession key, and any other token linked to the same >> key overwrites existing token at the RS. >> >> I think the intend is to avoid having multiple access token that >> could >> have the same PoP with different permissions. Keeping only the latest >> does not >> guarantee the client and the broker are considering the same ticket, and >> MAY >> force client to perform a two step authentication at any time. In case o= f >> rekey >> or synchronization issues, this might generate more traffic than needed.= I >> would think that keeping track of the access token used by DTLS is safer= , >> the >> way described here is only one way of doing it. >> > > [CS] This is coming from draft-ietf-ace-oauth-authz, Page 37: > > This specification RECOMMENDS that an RS stores only one token per > proof-of-possession key, meaning that an additional token linked to > the same key will overwrite any existing token at the RS. > > I would like to follow this recommendation in this profile as it greatly > simplifies the implementation. > And, during a long MQTT session, the client may push new tokens. The > behaviour should be the new token overwrites the old one. > > I understand, the motivation, maybe we should keep the mechanisms described as RECOMMENDED only rather than having this normative. That said, I am fine with what the WG thinks. > >> 2.2.4.1. Proof-of-Possession Using a Challenge from the TLS session >> >> For this option, the Authentication Data MUST contain the token and >> the keyed message digest (MAC) or the Client signature. The secret >> that is used for the proof-of-possession calculation, i.e., to >> calculate the keyed message digest (MAC) or the Client signature, is >> obtained using a TLS exporter ([RFC5705] for TLS 1.2 and for TLS 1.3, >> Section 7.5 of [RFC8446]). >> >> Just to make sure I follow, the secret is signed or MACed without >> being >> sent. The secret is not used to derive the key used to the signature or >> MAC. >> Instead this key is in the access token. If I am correct, the use of MA= C >> or >> signature is defined by the PoP symmetric or asymmetric. Correct ? I >> believe >> the text could be clearer. >> > > Yes, correct. Added to the github issue to make this text clearer: > https://github.com/ace-wg/mqtt-tls-profile/issues/41 > > >> >> 2.2.4.2. Proof-of-Possession via Broker-generated Challenge/Response >> >> For this option, the RS follows a Broker-generated challenge/response >> protocol. The success case is illustrated in Figure 4. If the >> Authentication Data only includes the token, the RS MUST respond with >> an AUTH packet, with the Authenticate Reason Code set to '0x18 >> (Continue Authentication)'. This packet includes the Authentication >> Method, which MUST be set to 'ace' and Authentication Data. The >> Authentication Data MUST NOT be empty and contains an 8-byte nonce as >> a challenge for the Client. The Client responds to this with an AUTH >> packet with a reason code '0x18 (Continue Authentication)'. >> Similarly, the Client packet sets the Authentication Method to 'ace'. >> The Authentication Data in the Client's response contains a client- >> generated 8-byte nonce, and the signature or MAC computed over the RS >> nonce concatenated with the client nonce. Next, the token is >> validated as described in Section 2.2.5. >> >> >> I do not see exporters being involved, and if that is correct ther= e >> is no >> channel binding. As DTLS is mandatory, wouldn't it be possible to add th= e >> exporter to the nonces. This may also be used to increases the randomnes= s >> of >> the nonces >> >> > [CS] I have to admit, I have gone back and forth about this. > Some implementers have commented not to have TLS exporter support... > > Unless there is a clear decision from the WG, I believe this shoul= d > discussed by the WG, and maybe documented in the document or the security > considerations. > > >> [...] >> >> 3.1. PUBLISH Messages from the Publisher Client to the Broker >> >> On receiving the PUBLISH message, the Broker MUST use the type of >> message (i.e., PUBLISH) and the Topic name in the message header to >> match against the scope string in the cached token or its >> introspection result. Following the example above, a client sending >> a PUBLISH message to 'a/topic3' would be allowed to publish, as the >> scope includes the string 'publish_+/topic3'. >> >> If the Client is allowed to publish to the topic, the RS must publish >> >> While "must" may not be necessary, if used, it could be >> normative. >> > > [CS] I tried to keep MQTT musts as "must" and this profile's musts as > MUST. > Wouldn't that be acceptable? > > I am fine with this alternative, so maybe you should clearly indicate in the section that this document is not normative to MQTT, you only use the normative language for the profile. If that is the only section, please add this to the section otherwise in the terminology section. It is good you keep must then, and implementer will interpret them a MUST without the authority for them. > >> 3.2. PUBLISH Messages from the Broker to the Subscriber Clients >> >> To forward PUBLISH messages to the subscribing Clients, the Broker >> identifies all the subscribers that have valid matching topic >> subscriptions (i.e., the tokens are valid, and token scopes allow a >> subscription to the particular topic). The Broker sends a PUBLISH >> message with the Topic name to all the valid subscribers. >> >> RS MUST stop forwarding messages to the unauthorized subscribers. >> >> I do not think they should have started. I am wondering if >> s/stop/NOT/ >> would not be better. >> > > [CS] Fixed. > > >> >> 4. Token Expiration and Reauthentication >> >> >> To re-authenticate, the Client sends an AUTH packet with reason code >> '0x19 (Re-authentication)'. The Client MUST set the Authentication >> Method as 'ace' and transport the new token in the Authentication >> Data. The Client and the RS go through the same steps for proof of >> possession validation as described in Section 2.2. The Client SHOULD >> use the same method used for the first connection request. >> >> I am wondering if there are good reasons for SHOULD. I would say >> that >> using multiple authentication method with different level of trust SHOUL= D >> be >> avoided. >> > > [CS] I am not sure any more if that sentence is necessary.... > > Thanks for your review again, > --Cigdem > > > >> >> On Fri, Jan 17, 2020 at 9:40 PM Jim Schaad >> wrote: >> >>> >>> >>> >>> >>> *From:* Cigdem Sengul >>> *Sent:* Tuesday, January 14, 2020 8:25 AM >>> *To:* Jim Schaad >>> *Cc:* draft-ietf-ace-mqtt-tls-profile@ietf.org; Ace Wg >>> *Subject:* Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-03 >>> >>> >>> >>> Thank you for this review, Jim. >>> >>> Responses inline. >>> >>> >>> >>> On Wed, Jan 1, 2020 at 10:33 PM Jim Schaad >>> wrote: >>> >>> >>> >>> >>> 2.2.2 - I am unclear under what circumstances you could end put with a >>> token >>> which does not parse when processing a PUBLISH message. If the token >>> cannot >>> be parsed at connection time, that I can understand. However having >>> parsed >>> the token then it does not make sense that the token becomes not >>> parsable at >>> the time of publishing. Am I missing something? >>> >>> >>> >>> [CS] There is a misunderstanding. The PUBLISH message refers to the >>> actual PUBLISH message to the "authz-info" topic which contains the tok= en >>> i.e., this may not parse to a token. (The PUBLISH message is not for ot= her >>> messages that are permissioned in the token.) >>> >>> The client connects (without much security), publishes the token to the >>> public "authz-info" topic, which only the broker can read. >>> >>> Then, disconnects, and tries to connect with ace security. >>> >>> >>> >>> Since MQTT v5 can return error messages in response to PUBLISH messages= , >>> here, this is used to signal to the publisher that there is something w= rong >>> with its token. >>> >>> >>> >>> Added: https://github.com/ace-wg/mqtt-tls-profile/issues/38 >>> >>> >>> >>> [JLS] Ok =E2=80=93 I see where I got mixed in in reading this. I think= this may >>> just be a problem on my end and you might not be able to do this better= . >>> >>> >>> >>> >>> >>> >>> >>> >>> 2.2.4 - I am having a problem with trying to parse the content of the >>> AUTH >>> property. I have no problems with 2.2.4.3 because this is a zero lengt= h >>> sequence of bytes. However for 2.2.4.1 and 2.2.4.2 there is a token >>> (possibly binary with no length prefix) followed by an optional binary >>> cryptographic value. For introspection, I would need to figure out the >>> length of the token before I could make a guess at the length of the >>> cryptographic value. However given that there is no divider this does >>> not >>> seem possible. This may also become a problem for the response from th= e >>> client in the event that there is a change from an 8-byte nonce to a >>> variable length one. >>> >>> >>> >>> [CS] Not specified a format, because I thought we discarded the idea >>> of using the variable-length nonce based on the meeting in Singapore. >>> >>> What would you suggest - introduce a specific format to accommodate >>> variable length? >>> >>> length_of_token+binary data for token+(the rest is cryptographic value)= ? >>> >>> https://github.com/ace-wg/mqtt-tls-profile/issues/40 >>> >>> >>> >>> [JLS] I put in a comment on the github issue about what I was looking >>> for. Additionally, my only possible problem with the fixed size nonce= is >>> that the IESG or Security Directorate down the line may decide that it = is >>> too small for some reason (16 bytes signed by a 521-bit (65+ byte key))= . >>> Some might consider it to be small for a SHA-256 MAC operation. Not th= e >>> exact same situation here for TLS as it is not really a compact protoco= l. >>> But it may considered to be for the IoT variants being used. I don=E2= =80=99t know. >>> >>> >>> >>> >>> >>> Jim >>> >>> >>> >>> >>> I am going to play with something else. I am sure I will find other >>> issues >>> at a different time. >>> >>> >>> >>> Thank you for your review. Much appreciated. >>> >>> --Cigdem >>> >>> >>> >>> >>> Jim >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Nits: >>> Section 2 Para 1 s/Broker.Figure 1/Broker. Figure 1/ >>> Section 2 Para 1 s/setup.The/setup. The/ >>> Section 2.2.2 Last Para s/when the AS/when the RS/ >>> >>> >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >>> >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace >>> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >> > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --00000000000064253a059d48834f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the comments, please see my responses. I h= ave not answered comments I had nothing to add in order to ease the readabi= lity of the thread. That said, I thank=C2=A0you for addressing them.=C2=A0<= /div>

In my opinion, there are a few comments, that need= s the WG to state how to address those, and I hope the interim meeting will= help. My expectation is that the next version will need to reviewed by a w= ider audience in the WG so the draft can be moved forward.=C2=A0
=
Yours,=C2=A0
Daniel

On Wed, Jan 29, 2020 at 7:10 AM= Cigdem Sengul <cigdem.sengul= @gmail.com> wrote:
Thank yo= u for your review Daniel.
Comments inside.

On Tue, Jan 21, 2= 020 at 6:23 PM Daniel Migault <daniel.migault=3D40ericsson.com@dmarc.ietf.org> wrote:

=C2=A0 =C2=A0In this document, topics, more specific= ally, Topic Names, are treated
=C2=A0 =C2=A0as resources.=C2=A0 The Clie= nts are assumed to have identified the
=C2=A0 =C2=A0publish/subscribe to= pics of interest out-of-band (topic discovery is
=C2=A0 =C2=A0not a feat= ure of the MQTT protocol).=C2=A0 A resource owner can pre-
=C2=A0 =C2=A0= configure policies at the AS that give Clients publish or subscribe
=C2= =A0 =C2=A0permissions to different topics.

<mglt> AS should be= expanded. As we introduce the ACE terminology, it might be
good to spec= ify if "resource" terminology is used related to RS. I am not
= entirely sure... but if that is the case, it might be good to specify that<= br>these resources are hosted on a Resource Server.

Though this is = a very minor issue, there are multiple double spaces.</mglt>

<= div>Blank spaces: Noted, will take care of them in the next version.=C2=A0<= /div>

=C2=A0
=C2=A0 =C2=A0Clients use an access token, bound = to a proof-of-possession (PoP) key to
authorize with the MQTT Broker the= ir connection and publish/ subscribe
permissions to topics.

<= mglt>Though I am an not english native, I have difficulties to parse &qu= ot;to
authorize with the MQTT Broker..." This is what I understand = from the draft:
The permission to publish/suscbribe topics on a given MQ= TT Broker are defined
by an =C2=A0access token, bound to a proof-of-poss= ession (PoP) key. The token is
provided by the AS and used by the Client= 's to access the RS. </mglt>
[CS] OK. Changed to "Clients prove their permission to pub= lish/subscribe to topics hosted on an MQTT broker using an access token, bo= und to a proof-of-possession (PoP) key."
Is this more clear.= =C2=A0

=C2=A0In the context of this ACE profile, the Broker acts asthe Resource Server (RS).=C2=A0 In the rest of the document the terms &qu= ot;RS" and
"Broker" are used interchangeably.=C2=A0 This = document describes how to authorise
the following exchanges between the = Clients and the Broker.

<mglt>How to authorize... The wording = sounds to me a bit strange though I would
not pretend to have a better w= ording either, wouldn't associated permission
more in line with the = ACE framework ?</mglt>

[CS] Fixed authorize. Kept the rest the same....

=C2=A0
<= /blockquote>

[CS] Fixed.=C2=A0


Sengul, et al. = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires June 22, 2020 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 3]
=0C
Internet-D= raft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MQTT-TLS profile of ACE =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 December 2019


=C2=A0 =C2=A0not signed o= r encrypted separately for the subscribers.=C2=A0 This

<mglt> =
It is the first time the document mentions PUBLISH. It would worth mayb= e to
specify it is an MQTT message.

I am wondering if encrypted = stands for the opposite of not signed. If so, a
document may be signed b= ut not encrypted.=C2=A0 I also understand that the security
is performed= by TLS or similar mechanism. If that is correct, it might be
clarifying= to mention this is what we have in mind.=C2=A0 It is also unclear why weintroduce subscribers and not Clients. Are we excluding intentionally the=
publishers?
=C2=A0
Maybe wording around: the PUBLISH message is u= nprotected or protected
via TLS (or equivalent mechanisms) for each Clie= nt's session. . =C2=A0

What is unclear to me is what the "c= ontent" of the PUBLISH message represents.
If that is the data asso= ciated to the topic. I would have expected
authentication being performe= d by a signature mechanism and the signature being
generated by the cont= ent owner, that is (I expect) the publisher. I think that
data protectio= n is out-of scope as well as MQTT based mechanisms as MQTT
recommends TL= S.

</mglt>

[CS] Preceded= the sentence with "Clients use MQTT PUBLISH message to publish to a t= opic."

What I meant was protecting the payloa= d from the Broker. At the moment, the broker is the end of TLS sessions for= clients.=C2=A0
So, the Broker does see all the payloads -> if= we would like to introduce "confidential topics", which is the p= ub-sub document Francesca is working on,=C2=A0
then the payload n= eeds to be encrypted.=C2=A0 Publishers do not sign the payload either.=C2= =A0

Not excluding publishers really, it is just th= at the subscribers are the recipients who would need to check the signature= , decrypt if things were protected.
Reworded as: "The docume= nt does not protect the payload of the PUBLISH message from the Broker, and= hence, the payload is not signed or encrypted
specifically for s= ubscribers."=C2=A0
=C2=A0
=C2=A0

=C2=A0 = =C2=A0functionality may be implemented using the proposal outlined in the=C2=A0 =C2=A0CoAP Pub-Sub Profile [I-D.palombini-ace-coap-pubsub-profile]= .


=C2=A0 =C2=A0To provide communication confidentiality and RS a= uthentication, TLS
=C2=A0 =C2=A0is used and TLS 1.3 is RECOMMENDED.=C2= =A0 This document makes the same
=C2=A0 =C2=A0assumptions as the Section= 4 of the ACE framework
=C2=A0 =C2=A0[I-D.ietf-ace-oauth-authz] regardin= g Client and RS registration with
=C2=A0 =C2=A0the AS and setting up key= ing material.

<mglt> Is registration appropriated for the RS = to the AS? </mglt>

=C2=A0 =C2=A0potentially in a similar way as the client has been re= gistered with
=C2=A0 =C2=A0the AS." in Section 4 of=C2=A0draft-ietf= -ace-oauth-authz.=C2=A0
<= div>
=
=C2=A0The Client-= AS and RS-AS may also be other
=C2=A0 =C2=A0than HTTPS e.g., CoAP or MQT= T. =C2=A0

<mglt>I suspect some words are missing. Maybe "= may also use other transport
protocol to carry the JWT.<.mglt>
=

[CS] Corrected to: "The C= lient-AS and RS-AS=C2=A0 MAY also use protocols other than HTTP e.g., CoAP = or MQTT."=C2=A0

1.2.=C2=A0 ACE-Related Terminology

=C2=A0= =C2=A0The terminology for entities in the architecture is defined in OAuth=
=C2=A0 =C2=A02.0 RFC 6749 [RFC6749] such as "Client" (C), &qu= ot;Resource Server" (RS)
=C2=A0 =C2=A0and "Authorization Serve= r" (AS).

=C2=A0 =C2=A0The term "Resource" is used to = refer to an MQTT Topic Name, which is
=C2=A0 =C2=A0defined in Section 1.= 3..=C2=A0 Hence, the "Resource Owner" is any entity
=C2=A0 =C2= =A0that can authoritatively speak for the topic.

<mglt>The int= roduction is using "resource", I propose the introduction text is=
coherent with the Terminology used latter in the document. </mglt>= ;

[CS] Changed to "re= source".=C2=A0
=C2=A0

1.3.=C2=A0 MQTT-Related Terminol= ogy

=C2=A0 =C2=A0The document describes message exchanges as MQTT pr= otocol
=C2=A0 =C2=A0interactions.=C2=A0 The Clients are MQTT Clients, wh= ich connect to the
=C2=A0 =C2=A0Broker to publish and subscribe to Appli= cation Messages, labeled with
=C2=A0 =C2=A0their topics.=C2=A0 For addit= ional information, please refer to the MQTT
=C2=A0 =C2=A0v5.0 - the OASI= S Standard [MQTT-OASIS-Standard-v5] or the MQTT v3.1.1
=C2=A0 =C2=A0- th= e OASIS Standard [MQTT-OASIS-Standard].

=C2=A0 =C2=A0MQTTS
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Secured transport profile of MQTT.=C2=A0= MQTTS runs over TLS.

<mglt> I am wondering how appropriated i= t is to have sentence without verb. I
probably think it is safer to use = verb.</mglt>

[CS] In = other IETF drafts, I typically see a definition without a verb.
=



=C2=A0 =C2=A0Broker
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0The Server in MQTT.=C2=A0 It acts as an intermediary between the
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Clients that publishes Application Me= ssages, and the Clients
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that ma= de Subscriptions.=C2=A0 The Broker acts as the Resource
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Server for the Clients.

<mglt>Simil= ar comment as before, there seems to have a missing verb.=C2=A0 While
Br= oker is defined, Client is not defined as a special term but instead in the=
introduction of the section. I am wondering if that would not be cleane= r to
have Client also be defined. I am also wondering if Clients cannot = be
designated as subscriber/publisher. Note this is a question I am wond= ering, and
I do not think a specific terminology would be needed. Instea= d, I would simply
suggest, that Clients includes subscribers and publish= ers as these terms are
used later. =C2=A0</mglt>



=C2=A0 =C2=A0Topic Filt= er
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0An expression that indicates= interest in one or more Topic
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Names.=C2=A0 Topic Filters may include wildcards.

=C2=A0 =C2=A0MQTT = sends various control messages across a network connection.=C2=A0 The
= =C2=A0 =C2=A0following is not an exhaustive list and the control packets th= at are
=C2=A0 =C2=A0not relevant for authorization are not explained.=C2= =A0 These include, for
=C2=A0 =C2=A0instance, the PUBREL and PUBCOMP pac= kets used in the 4-step handshake
=C2=A0 =C2=A0required for the QoS leve= l 2.

<mglt>As a general comment, I would recommend to have the= same definition as
those provided by MQTTv5. We could clearly mention t= hese are from MQTTv5 and
are repeated here for the document to self cont= ained. There is probably a
balance to find to introduce terms that are n= ot used in this document, so some
definitions may be partial using [....= ]. This is mostly a suggestion. </mglt>
=C2=A0<= /div>
=C2=A0
=C2=A0 =C2=A0CONNECT=




Sengul, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Expires June 22, 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 [Page 5]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= MQTT-TLS profile of ACE =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 December 2019

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Client request to connec= t to the Broker.=C2=A0 After a network
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0connection is established, this is the first packet sent by a
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Client.

<mglt>I under= stand that network connection means the layers below MQTT. I thing
this = is confusing and would suggest to maybe remove "After a network connec= tion
is established,"</mglt>

[CS] OK. But, if we are following the advice of sticking wi= th MQTT spec for definitions, here is what the original says:
&qu= ot;After a Network Connection is est= ablished by a Client to a Server, the first packet sent from the Client to = the Server MUST be a CONNECT packet".=C2=A0

<= /blockquote>


=C2=A0 =C2=A0SUBSCRIBE
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The Client subscribe request.

<= mglt>I would suggest to have similar wording for PUBLISH as for
SUBSC= RIBE.</mglt>

[CS] Cha= nged to: "Subscribe request sent from a Client".=C2=A0
= =C2=A0

2.=C2=A0 Authorizing Connection Requests

=C2=A0 =C2=A0T= his section specifies how Client connections are authorized by the
=C2= =A0 =C2=A0MQTT Broker.Figure 1 shows the basic protocol flow during connect= ion
=C2=A0 =C2=A0set-up.The token request and response use the /token en= dpoint at the

<mglt> I suspect "/" should not be her= e and that url path is not
intended.</mglt>


[CS] Fixed.
=C2=A0
[...]

2= .2.1..=C2=A0 Client-Server Authentication over TLS and MQTT

=C2=A0 = =C2=A0The Client and the Broker MUST perform mutual authentication. =C2=A0<= br>
<mglt>If I am correct this is also correct for the C-AS.</m= glt>
[CS] Yes, added to the previous se= ction.=C2=A0
Actually: According to=C2=A0=20 draft-ietf-ace-oauth-authz: It is also REQUIRED that the
=C2=A0 =C2=A0= communicating endpoints perform mutual authentication.
Should it be rep= eated in the profile as well?=C2=A0

<= /blockquote>
<mglt>I would suggest yes, otherwise we wonder while= the profile only provide one part of it. </mglt2>=C2=A0


=C2=A0The
=C2=A0= =C2=A0Client MAY authenticate to the Broker over MQTT or TLS.

<= mglt>My understanding of the sentence above is that the Client MAY
au= thenticate. Unless I am missing something, I would rather see MUST
inste= ad.</mglt>

[CS]OK. Th= e previous sentence say the Client MUST authenticate.
It may use = either MQTT=C2=A0 or TLS to authenticate.
Still, I changed the se= ntence to:
"Client MUST authenticate to the Broker either ov= er MQTT or TLS".=C2=A0
=C2=A0
<mglt2>The difference is that we do limit the mechanisms u= sed to authenticate.</mglt2>=C2=A0
=C2=A0
<= div dir=3D"ltr">
=C2=A0 =C2=A0For MQTT,
=C2=A0 =C2=A0the options are= "None" and "ace".=C2=A0 For TLS, the options are "= ;Anon"
=C2=A0 =C2=A0for anonynous client, and "Known(RPK/PSK)&= quot; for Raw Public Keys (RPK)
=C2=A0 =C2=A0and Pre-Shared Keys (PSK), = respectively.=C2=A0 Combined, the Client
=C2=A0 =C2=A0authentication tak= es the following options:

=C2=A0 =C2=A0o =C2=A0"TLS:Anon-MQTT:N= one": This option is used only for the topics that
=C2=A0 =C2=A0 = =C2=A0 do not require authorization, including the "authz-info" t= opic.
=C2=A0 =C2=A0 =C2=A0 Publishing to the "authz-info" topi= c is described in
=C2=A0 =C2=A0 =C2=A0 Section 2.2.2.

<mglt>= ;It is a bit unseal to describe unauthenticated channel as mutually
auth= enticated.</mglt>

[CS= ] Himmm, not sure how to deal with this. This is the first step to the Mutu= al authentication.=C2=A0
I can take this out describe separately.= And then have only 3 options for mutual authentication.=C2=A0
An= y thoughts?
=C2=A0
=C2=A0
=C2=A0 =C2=A0o =C2=A0"= TLS:Anon-MQTT:ace": The token is transported inside the CONNECT messag= e,
and MUST be validated using one of the methods described in Section 2= .2.2.
This option also supports a tokenless connection request for AS di= scovery.

=C2=A0 =C2=A0o =C2=A0"TLS:Known(RPK/PSK)-MQTT:none&quo= t;: For the RPK, the token MUST have
=C2=A0 =C2=A0 =C2=A0 been published= to the "authz-info" topic.=C2=A0 For the PSK, the token
=C2= =A0 =C2=A0 =C2=A0 MAY be, alternatively, provided in the "psk_identity= ".=C2=A0 The TLS
=C2=A0 =C2=A0 =C2=A0 session set-up is as describe= d in DTLS profile for ACE
=C2=A0 =C2=A0 =C2=A0 [I-D.ietf-ace-dtls-author= ize].

<mglt> Just to me sure I understand it properly. In this= case the RPK or PSK is
the one contained into the token. DTLS authentic= ate the TLS client via a
CertificateRequest. Other information related t= o the topic are performed by the
MQTT. In order to perform perform the T= LS authentication, the token with the
existing key needs to be found. Th= e Broker upon receiving a CONNECT needs to
keep track of the used token.= =C2=A0</mglt>

[CS] W= e use TLS - give the DTLS profile as an example of the set-up for ACE.=C2= =A0
Yes: The token is validated, the client is authenticated, a s= ecure TLS channel with them using the info in the token.=C2=A0
Th= e topic authorisation happens when the client tries to publish or subscribe= .=C2=A0
=C2=A0

=C2=A0 =C2=A0o =C2=A0"TLS:Known(RPK/PSK)-MQTT:ace"= : This option SHOULD NOT be chosen.
=C2=A0 =C2=A0 =C2=A0 In any case, th= e token transported in the CONNECT overwrites any
=C2=A0 =C2=A0 =C2=A0 p= ermissions passed during the TLS authentication.

<mglt>My unde= rstanding is that the same access token would be used. Collision
would o= ccurs when different access token would be used. However, when
authentic= ation is performed using DTLS, the Broker, as I would understand it,
kee= ps track of the used token, which should avoid the overwriting rules.</m= glt>

[CS] This statement= was in case two different tokens were used, the last valid token overwrite= s the former.=C2=A0
i.e., u can not add to your permissions - the= re is no union.=C2=A0
=C2=A0
<mglt2> I have the impression that the requirements is to en= sure one token is being used when more token are available. The document pr= ovides one way to do, but does not leave room to other mechanisms or implem= entation. I am wondering if that is something we want or if I am missing so= mething.</mglt2>=C2=A0
=

=C2=A0 =C2=A0It is RECOMMENDED that the Client follows TLS:Anon-MQ= TT:ace.

=C2=A0 =C2=A0The Broker MUST be authenticated during the TLS= handshake.=C2=A0 If the
=C2=A0 =C2=A0Client authentication uses TLS:Kno= wn(RPK/PSK), then the Broker is
=C2=A0 =C2=A0authenticated using the res= pective method.

<mglt>I understand that when the server is aut= henticated using RPK, the server
needs to be authenticated using RPK, bu= t it is unclear why standard WPKI would
not work. I understand that for = PSK the same method can be used, though.
</mglt>

[CS] The language around TLS may have gotten more const= rained because I wanted to follow roughly=C2=A0
what DTLS profile= for ACE says...=C2=A0
Though I do not have specific experience w= ith WPKI.=C2=A0
=C2=A0
<mglt>needs to be clarifie= d by the WG.</mglt>
=C2=A0
2.2.2. =C2=A0authz-info: The Authoriza= tion Information Topic


=C2=A0 =C2=A0The Broker stores and indexe= s all tokens received to this topic in
=C2=A0 =C2=A0its key store simila= r to DTLS profile for ACE
=C2=A0 =C2=A0[I-D.ietf-ace-dtls-authorize].=C2= =A0 This profile follows the
=C2=A0 =C2=A0recommendation of Section 5.8.= 1 of ACE framework
=C2=A0 =C2=A0[I-D.ietf-ace-oauth-authz], and expects = that RS stores only one token
=C2=A0 =C2=A0per proof-of-possession key, = and any other token linked to the same
=C2=A0 =C2=A0key overwrites exist= ing token at the RS.

<mglt>I think the intend is to avoid havi= ng multiple access token that could
have the same PoP with different per= missions. Keeping only the latest does not
guarantee the client and the = broker are considering the same ticket, and MAY
force client to perform = a two step authentication at any time. In case of rekey
or synchronizati= on issues, this might generate more traffic than needed. I
would think t= hat keeping track of the access token used by DTLS is safer, the
way des= cribed here is only one way of doing it. </mglt>

[CS] This is coming from=C2=A0draft-ietf-ace-o= auth-authz, Page 37:

This specification RECOMMENDS= that an RS stores only one token per
=C2=A0 =C2=A0proof-of-possession= key, meaning that an additional token linked to
=C2=A0 =C2=A0the same k= ey will overwrite any existing token at the RS.=C2=A0

I would like to follow this= recommendation in this profile as it greatly simplifies the implementation= .=C2=A0
And, during a long MQTT session, th= e client may=C2=A0 push new tokens. The behaviour should be the new token o= verwrites the old one.=C2=A0


<mglt>I understand,=C2=A0 th= e motivation, maybe we should keep the mechanisms described as RECOMMENDED = only rather than having this normative. That said, I am fine with what the = WG thinks.</mglt>
=C2=A0

2.2.4.1.=C2=A0 Proof-of-Possession= Using a Challenge from the TLS session

=C2=A0 =C2=A0For this option= , the Authentication Data MUST contain the token and
=C2=A0 =C2=A0the ke= yed message digest (MAC) or the Client signature.=C2=A0 The secret
=C2= =A0 =C2=A0that is used for the proof-of-possession calculation, i.e., to=C2=A0 =C2=A0calculate the keyed message digest (MAC) or the Client signat= ure, is
=C2=A0 =C2=A0obtained using a TLS exporter ([RFC5705] for TLS 1.= 2 and for TLS 1.3,
=C2=A0 =C2=A0Section 7.5 of [RFC8446]).

<m= glt>Just to make sure I follow, the secret is signed or MACed without be= ing
sent. The secret is not used to derive the key used to the signature= or MAC.
Instead this key is in the access token.=C2=A0 If I am correct,= the use of MAC or
signature is defined by the PoP symmetric or asymmetr= ic. Correct ? I believe
the text could be clearer. =C2=A0</mglt>

Yes, correct. Added to the g= ithub issue to make this text clearer:
=C2=A0
<= br>2.2.4.2.=C2=A0 Proof-of-Possession via Broker-generated Challenge/Respon= se

=C2=A0 =C2=A0For this option, the RS follows a Broker-generated c= hallenge/response
=C2=A0 =C2=A0protocol.=C2=A0 The success case is illus= trated in Figure 4.=C2=A0 If the
=C2=A0 =C2=A0Authentication Data only i= ncludes the token, the RS MUST respond with
=C2=A0 =C2=A0an AUTH packet,= with the Authenticate Reason Code set to '0x18
=C2=A0 =C2=A0(Contin= ue Authentication)'.=C2=A0 This packet includes the Authentication
= =C2=A0 =C2=A0Method, which MUST be set to 'ace' and Authentication = Data.=C2=A0 The
=C2=A0 =C2=A0Authentication Data MUST NOT be empty and c= ontains an 8-byte nonce as
=C2=A0 =C2=A0a challenge for the Client.=C2= =A0 The Client responds to this with an AUTH
=C2=A0 =C2=A0packet with a = reason code '0x18 (Continue Authentication)'.
=C2=A0 =C2=A0Simil= arly, the Client packet sets the Authentication Method to 'ace'.=C2=A0 =C2=A0The Authentication Data in the Client's response contains= a client-
=C2=A0 =C2=A0generated 8-byte nonce, and the signature or MAC= computed over the RS
=C2=A0 =C2=A0nonce concatenated with the client no= nce.=C2=A0 Next, the token is
=C2=A0 =C2=A0validated as described in Sec= tion 2.2.5.


<mglt>I do not see exporters being involved, a= nd if that is correct there is no
channel binding. As DTLS is mandatory,= wouldn't it be possible to add the
exporter to the nonces. This may= also be used to increases the randomness of
the nonces</mglt>
=

[CS] I have to admit, I ha= ve gone back and forth about this.=C2=A0
Some implementers have c= ommented not to have=C2=A0 TLS exporter support...=C2=A0

<mglt> Unless there is a clear decision from the WG, I believe= this should discussed by the WG, and maybe documented in the document or t= he security considerations. </mglt>=C2=A0
=C2=A0
[...]
3.1.=C2=A0 PUBLISH Messages from the Publisher Client to the Broker
=C2=A0 =C2=A0On receiving the PUBLISH message, the Broker MUST use the= type of
=C2=A0 =C2=A0message (i.e., PUBLISH) and the Topic name in the = message header to
=C2=A0 =C2=A0match against the scope string in the cac= hed token or its
=C2=A0 =C2=A0introspection result.=C2=A0 Following the = example above, a client sending
=C2=A0 =C2=A0a PUBLISH message to 'a= /topic3' would be allowed to publish, as the
=C2=A0 =C2=A0scope incl= udes the string 'publish_+/topic3'.

=C2=A0 =C2=A0If the Clie= nt is allowed to publish to the topic, the RS must publish

<mglt&= gt;While "must" may not be necessary, if used, it could be normat= ive.</mglt>

[CS] I tr= ied to keep MQTT musts as "must" and=C2=A0 this profile's mus= ts as MUST.=C2=A0
Wouldn't that be acceptable?
=C2= =A0
<mglt> I am fine with th= is alternative, so maybe you should clearly indicate in the section that th= is document is not normative to MQTT, you only use the normative language f= or the profile. If that is the only section, please add this to the section= otherwise in the terminology section. It is good you keep must then, and i= mplementer will interpret them a MUST without the authority for them.</m= glt>

=C2=A0

3.2.=C2=A0 PUBLISH Messages from the Broker to the Subscriber Client= s

=C2=A0 =C2=A0To forward PUBLISH messages to the subscribing Client= s, the Broker
=C2=A0 =C2=A0identifies all the subscribers that have vali= d matching topic
=C2=A0 =C2=A0subscriptions (i.e., the tokens are valid,= and token scopes allow a
=C2=A0 =C2=A0subscription to the particular to= pic).=C2=A0 The Broker sends a PUBLISH
=C2=A0 =C2=A0message with the Top= ic name to all the valid subscribers.

=C2=A0 =C2=A0RS MUST stop forw= arding messages to the unauthorized subscribers.

<mgtl>I do no= t think they should have started. I am wondering if s/stop/NOT/
would no= t be better.</mglt>

[= CS] Fixed.
=C2=A0

4.=C2=A0 Token Expiration and Reauthentic= ation


=C2=A0 =C2=A0To re-authenticate, the Client sends an AUTH = packet with reason code
=C2=A0 =C2=A0'0x19 (Re-authentication)'.= =C2=A0 The Client MUST set the Authentication
=C2=A0 =C2=A0Method as = 9;ace' and transport the new token in the Authentication
=C2=A0 =C2= =A0Data.=C2=A0 The Client and the RS go through the same steps for proof of=
=C2=A0 =C2=A0possession validation as described in Section 2.2.=C2=A0 T= he Client SHOULD
=C2=A0 =C2=A0use the same method used for the first con= nection request.

<mglt>I am wondering if there are good reaso= ns for SHOULD. I would say that
using multiple authentication method wit= h different level of trust SHOULD be
avoided. </mglt>

[CS] I am not sure any more if that sen= tence is necessary....

Thanks for your review agai= n,
--Cigdem=C2=A0




On Fr= i, Jan 17, 2020 at 9:40 PM Jim Schaad <ietf@augustcellars.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
<= p class=3D"MsoNormal">=C2=A0

=C2=A0

From: Cigdem Sengul <cigdem.sengul@gma= il.com>
Sent: Tuesday, January 14, 2020 8:25 AM
To:= Jim Schaad <ietf@augustcellars.com>
Cc: draft-ietf-ace-mqtt-tl= s-profile@ietf.org; Ace Wg <ace@ietf.org>
Subject: Re: [Ace] Review of dra= ft-ietf-ace-mqtt-tls-profile-03

= =C2=A0

Thank = you for this review, Jim.=C2=A0

Responses inline.=C2=A0

=C2=A0

On Wed, J= an 1, 2020 at 10:33 PM Jim Schaad <ietf@augustcellars.com> wrote:<= /p>




2.2.2 - I am unclear under what circumstances you c= ould end put with a token
which does not parse when processing a PUBLISH= message.=C2=A0 If the token cannot
be parsed at connection time, that I= can understand.=C2=A0 However having parsed
the token then it does not = make sense that the token becomes not parsable at
the time of publishing= .=C2=A0 Am I missing something?

=C2=A0

[C= S] There is a misunderstanding. The PUBLISH message refers to the actual PU= BLISH message to the "authz-info" topic which contains the token = i.e., this may not parse to a token. (The PUBLISH message is not for other = messages that are permissioned in the token.)

<= p class=3D"MsoNormal">The client connects (without much security), publishe= s the token to the public "authz-info" topic, which only the brok= er can read.=C2=A0

Then,= disconnects, and tries to connect with ace security.=C2=A0

=C2=A0

Since MQTT v5 can return error messages in response to P= UBLISH messages, here, this is used to signal to the publisher that there i= s something wrong with its token.=C2=A0

=C2=A0

A= dded:=C2=A0https://github.com/ace-wg/mqtt-tls-profile/issues/38=

=C2=A0

[JLS] Ok =E2=80=93 I see where I got mixed in in reading thi= s.=C2=A0 I think this may just be a problem on my end and you might not be = able to do this better.

= =C2=A0

=C2=A0<= /u>

=C2=A0


2.2.4 - I am having a problem= with trying to parse the content of the AUTH
property.=C2=A0 I have no = problems with 2.2.4.3 because this is a zero length
sequence of bytes.= =C2=A0 However for 2.2.4.1 and 2.2.4.2 there is a token
(possibly binary= with no length prefix) followed by an optional binary
cryptographic val= ue.=C2=A0 For introspection, I would need to figure out the
length of th= e token before I could make a guess at the length of the
cryptographic v= alue.=C2=A0 However given that there is no divider this does not
seem po= ssible.=C2=A0 This may also become a problem for the response from the
c= lient in the event that there is a change from an 8-byte nonce to a
vari= able length one.

= =C2=A0

[CS] Not specifie= d a=C2=A0 format, because I=C2=A0 thought we discarded the idea of using th= e variable-length nonce based on the meeting in Singapore.=C2=A0<= /u>

What would you suggest - introduce= a specific format to accommodate variable length?

<= div>

length_of_token+binary data for token+(the rest = is cryptographic value)?

=C2=A0https://github.com/ace-wg/mqtt-tls-profile/issues/40<= /u>

=C2=A0

[JLS] I put in a comment on the github issue about what I was look= ing for.=C2=A0 Additionally,=C2=A0 my only possible problem with the fixed = size nonce is that the IESG or Security Directorate down the line may decid= e that it is too small for some reason (16 bytes signed by a 521-bit (65+ b= yte key)).=C2=A0 Some might consider it to be small for a SHA-256 MAC opera= tion.=C2=A0 Not the exact same situation here for TLS as it is not really a= compact protocol.=C2=A0 But it may considered to be for the IoT variants b= eing used.=C2=A0 I don=E2=80=99t know.

=C2=A0

=C2=A0

Jim

=C2=A0


I am going to play with something else.=C2=A0 I am sure= I will find other issues
at a different time.

=C2=A0

Thank you for your review. Much appreciated.=C2=A0

--Cigdem=C2=A0

=

=C2=A0


Jim







<= br>





Nits:
Section 2 Para 1 s/Broker.Figure 1/Brok= er.=C2=A0 Figure 1/
Section 2 Para 1=C2=A0 s/setup.The/setup.=C2=A0 The/=
Section 2.2.2 Last Para s/when the AS/when the RS/


_________= ______________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/= mailman/listinfo/ace

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--00000000000064253a059d48834f-- From nobody Wed Jan 29 07:26:44 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C0D12009C; Wed, 29 Jan 2020 07:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWyObFtNYWnz; Wed, 29 Jan 2020 07:26:40 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2152120020; Wed, 29 Jan 2020 07:26:39 -0800 (PST) Received: from wangari.tzi.org (eduroam-pool13-084.wlan.uni-bremen.de [134.102.160.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4876lf3rQ3zygC; Wed, 29 Jan 2020 16:26:38 +0100 (CET) From: Olaf Bergmann To: Daniel Migault Cc: ace-chairs@ietf.org, Ace Wg References: <1871924156.4933601578025456778.JavaMail.nobody@rva2rmd101.webex.com> Date: Wed, 29 Jan 2020 16:26:38 +0100 In-Reply-To: (Daniel Migault's message of "Fri, 24 Jan 2020 07:37:36 -0500") Message-ID: <87a766p9ld.fsf@wangari> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] Webex meeting invitation: ACE interim meeting X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 15:26:42 -0000 Hi, a quick status update for draft-ietf-ace-dtls-authorize-09: We have received an AD review and are currently working on the responses (delayed by high workload). Gr=C3=BC=C3=9Fe Olaf From nobody Thu Jan 30 15:16:30 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A8812022E; Thu, 30 Jan 2020 15:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.793 X-Spam-Level: X-Spam-Status: No, score=-0.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yf5NVD2VEtyx; Thu, 30 Jan 2020 15:16:28 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38EBE1200F7; Thu, 30 Jan 2020 15:16:25 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 30 Jan 2020 15:16:19 -0800 From: Jim Schaad To: CC: Date: Thu, 30 Jan 2020 15:16:17 -0800 Message-ID: <010b01d5d7c3$47d36ad0$d77a4070$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdXUuS1YkeMOHqDuQo661Ct1JSFA6w== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] draft-ietf-ace-key-groupcomm-oscore X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 23:16:29 -0000 This is not a finished review - but I wanted to get it out. Jim General - Should the concept of a legal requester be part of the information that is transported with the public key? I don't believe that this is currently done, but would additionally allow for a server to ignore comments from individuals who are not authorized for that role. Section 2.2 - must new security parameters be regenerated on each membership change? Section 2.2. - Does completion of a group rekeying include confirmed redistribution before the version number is incremented? Section 4.2.1 - I think that we are going to need a discussion on a couple of issues related to the OSCORE half of how these values are going to be created. Pieces of the discussion are: 1. What is the POP her going to try and prove. Specifically is timeliness part of the discussion. 2. What do we do about token which grants access to multiple topics. Is joining the second group considered to be a re-join rather than an original join for the purposes of this discussion? 3. What are the interactions about cached public keys, when are these ok and how is this communicated to the client as a failure? Section 4.3 - Does it make sense to return a new rsnoce as part of these errors? From nobody Thu Jan 30 15:16:49 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4971200F7; Thu, 30 Jan 2020 15:16:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSTDkFNTy8W1; Thu, 30 Jan 2020 15:16:46 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C0BC120026; Thu, 30 Jan 2020 15:16:43 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 30 Jan 2020 15:16:37 -0800 From: Jim Schaad To: CC: Date: Thu, 30 Jan 2020 15:16:36 -0800 Message-ID: <010c01d5d7c3$52ea77b0$f8bf6710$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdXQCzoDRJGtjzwzSJSGfp6QenWJMA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] Review for draft-ietf-ace-key-groupcomm-04 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jan 2020 23:16:47 -0000 This is not a finished review, but I wanted to get it out Jim Section 1 - last paragraph - the first sentence in this paragraph is giving me fits trying to understand it. I would suggest something, but I really don't understand it. General - Update the reference to RFC 7049 to the bis draft. Section 3.1 - Should we try and harmonize the scope format here with either the format in MQTT or with the one that Carsten once proposed. The multiplicity of scope formats is going to become a problem at some point. Section 3.1 - It might make sense to move the contents of the last paragraph of 'scope' up to the two points dealing with the elements. I had a brief moment where I thought REQ1 and REQ2 conflicting with the CBOR array. Section 3.2 - I think the definition of 'exp' is incorrect. Did you mean to use 'exi'? Section 3.2 - for scope - if the format is the same as in Section 3.1 - just say that and omit the details. Section 3.3 - Does REQ3 indicate that the profile is supposed to say that the set of valid algorithms is defined or that a set of identifiers different than that defined in the COSE Algorithm registry can be used. An example would be a text version of object identifiers. My current reading is that the latter is correct. Section 3.3.3 - I don't think that you can return an rsnounce at this point. There is nothing that ensures that one knows who the client is and thus one cannot tie the nonce to any specific client. Depending on what you are trying to prove with the POP interaction this may not be provable with this. Section 4.1 - Now does one enforce the MUST NOT for the resource name of /ace-group? Section 4.1.2.1 - I think that this is the "join". Using that word here will clarify what is going on. Section 4.1.2.1 - Once again - tell me why I care about scope in this location. Section 4.1 - I am not sure, but I think that I might want to suggest putting a node in the path between guid and the node id for a single end point. That is /ace-group/gid/nodes/node. This allows for one to not deal with potential name collisions with the other nodes under gid. Section 4.1.3.1 - Why can get_put_keys not be an empty array? Should this be a bad request error if it is empty? * - Should a client be able to ask for a previous set of keying material? Consider the case of a client having key material n, missing update n+1 and getting update n+2. The client then gets a message encrypted to update n+1. It never saw the material and thus cannot decrypt the message. Section 4.3 - first para - another condition is if it discovers that new keying material has been issued. (Either as a message with a new epoch or a notification from the server.) While this is covered in the second paragraph it is not clear that the client is going to stop using the key material in that case. Section 4.3 - para 3 - Is there a difference between not being able decrypt because of decryption failure rather than on the basis of not having key material to decrypt. That is type of failure makes a difference Section 4.4 - Policy can be that the KDC does a general rekey instead of just doing an individual rekey Section 6 - gkty does not match description - should be text string not byte string From nobody Thu Jan 30 18:37:59 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D3112006F; Thu, 30 Jan 2020 18:37:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k_gi9mk6WCOT; Thu, 30 Jan 2020 18:37:50 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0CE4120048; Thu, 30 Jan 2020 18:37:49 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 30 Jan 2020 18:37:39 -0800 From: Jim Schaad To: 'Francesca Palombini' , 'Benjamin Kaduk' , , 'Ace Wg' References: <20200107163851.GV57294@kduck.mit.edu> <4086FADE-7993-47F6-9292-FDD7FC5457B4@ericsson.com> In-Reply-To: <4086FADE-7993-47F6-9292-FDD7FC5457B4@ericsson.com> Date: Thu, 30 Jan 2020 18:37:37 -0800 Message-ID: <011401d5d7df$6845a050$38d0e0f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHqfviK1QMevhjdj3Y220tbueW5KgFfFDFLp8/CBgA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-oscore-profile-08 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 02:37:57 -0000 -----Original Message----- From: Ace On Behalf Of Francesca Palombini Sent: Wednesday, January 29, 2020 6:43 AM To: Benjamin Kaduk ; = draft-ietf-ace-oscore-profile@ietf.org; Ace Wg Subject: Re: [Ace] AD review of draft-ietf-ace-oscore-profile-08 Hi Ben, Thank you so much for this very thorough and in-depth review!=20 I have started a PR = (https://github.com/ace-wg/ace-oscore-profile/pull/25 ) where I plan to = include all the review comments. I have started with the editorial = fixes, which I have collected in one issue: = https://github.com/ace-wg/ace-oscore-profile/issues/24=20 The details of answers and additional questions for clarification are = inline, I also noted with "OK" the points where I agree with your = suggestion and don't see any problem implementing in the PR. I will keep = the numbering consistent in the mail thread and in the github to make = sure everything is covered. Additionally, you made a number of points I'd like to get wg opinion on: * The mechanism of letting the RS pick the identifier of the client is = not worth the additional complexity. So I propose we revert that, and go = back to AS MUST pick the clientId, the clientId MUST be included in the = token. This will only add some considerations about the scenario has = several-AS-per-RS, in which case these AS need to be synchronized on = clientIds they give out. (6., 21., 61., 65.) [JLS] For better or worse, this is not the only consideration. The = above statement presumes that only the AS is going to be assigning the = client identifiers. If the RS uses a different method of doing = authentication as well, such as LAKE, then there is a chance for = collisions at that point as well. * Recommendation about length of nonces N1 and N2 to use. The wg agreed = on 64 bits, now Ben suggests to use 128 bits nonces. Reminder: these = nonces are appended to the input salt to create the Master Salt, to run = the HKDF and derive the keys. Also consider that OSCORE appendix B2 has = a similar setting and does some considerations about that, mentioning = that "typically nonces of at least 8 bytes will be used". [JLS] I am agnostic on this, but I think that generally 64-bits from = each side is sufficient. This does add an additional 8 bytes of message = size when sending the token to the server. That worries me slightly. * Define and register 2 new ACE parameters to transport the nonces used = in the exchange, instead of using "cnonce". (see point 3., 53.) * Define the nonces as bstr so that length value is encoded. (7.) https://tools.ietf.org/html/rfc8613#page-72=20 * Editorial: point 75. Thanks again! Francesca =EF=BB=BFOn 07/01/2020, 17:40, "Ace on behalf of Benjamin Kaduk" = wrote: Hi all, =20 Some high-level points before the section-by-section commentary: =20 1. I'm a little confused by the registry we are creating in Section = 9.2. While it's clear that we need something to specify the CBOR map key labels to encode the structure for transit, it's not clear that we = need easy extensibility vs. a fixed table. A registry implies = expectations of future additions, but draft-ietf-core-object-security did not = feel a need to make a registry for future extensions; what has changed in = the past few months that makes extensibility needed now? Why is this document the right place to create the registry as opposed to that = one? =20 FP: Why extensibility now: an example is the Group OSCORE profile, which = extends this registry with fields that the OSCORE profile does not need, = related to countersignatures (see = https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-04#page-2= 2 ). The difference between OSCORE (RFC8613) and this doc is that in = OSCORE the security context is never sent on the wire, it is assumed to = be pre-established, while here we needed to define a structure to send. = Yes, we could avoid defining the registry and define all the fields (we = can think of right now), including those for ace-key-groupcomm-oscore as = a fixed table, but we thought this would be better, also considering = that the OSCORE security context could get extended in a future version = of OSCORE. 2. We are in some sense defining a new substructure within "kid" = values (a CBOR-encoded array of one or two elements) for usage by things using this profile. That's probably not problematic, as the "kid" can be = an arbitrary bstr and its interpretation is up to the recipient -- any recipient that implements this profile will know to handle the substructure, but it does feel a little unusual and perhaps worth an early note. (IIUC, we also need to be careful about actually = providing the bstr framing in our examples.) =20 FP: Ok, I will add an early note and also make sure the array is wrapped = in a bstr. Do you have any opinion on where best to add this note? Kid = appears first in 3.1, should we have it in the introductory section 3.? = Or were you thinking even before? 3. I'm concerned about the usage of "cnonce" to carry both N1 and N2, neither of which correspond to the "cnonce" behavior in the core framework; I think we should pick a different parameter name for the differeng semantic usage. Specifically, the core-framework "cnonce" = is a tool to give RSes some modicum of replay protection -- it verifies that the client's authorization in the token is "fresh", since the = token includes the random nonce generated by the RS and conveyd to the AS = via the client. This document uses a parameter named "cnonce" in two = ways: (1) to convey the client-generated nonce N1 to the RS in the = authz-info request; this is giving the client contributory behavior to the ephemeral randomness input to the Security Context computation but = does not provide any sort of replay-protection in and of itself (2) to convey the RS-generated nonce N2 back to the client in the authz-info response; this does serve as replay protection in some = sense, but in that it serves to cause repeated posting of the same token = (as might occur in a replay attack) to generate a different OSCORE = context (due to the RSes contributory nature) so that the resulting key = material will be unique for a given association, as opposed to detecting and blocking replay outright. I think all three uses should have = distinct parameter names, based on my current understanding. =20 FP: Yes, your understanding is right. I don't see any problem at all = with defining new parameters names for the nonces, the reason we used = "cnonce" is that this exact point was brought up in the wg and everybody = seemed to agree on no need to define a new one, despite the semantics of = "cnonce". The authors did not have a strong opinion. 4. We mention several times about getting protection from AEAD = nonce/key reuse, but to some extent leave it to the reader to figure out how = that works. Specifically, the only guidance we give on nonce selection = is for our N1 and N2 that go into the Master Salt; we don't say how = varying the Master Salt like that will cause the generated keys and (common) = IVs to differ across runs, thus by construction preventing the collision = of (key, nonce) pairs. (Implementation carelessness that just reuses key+nonce for a given Security Context is still possible, of = course.) =20 FP: Would it be sufficient to add a sentence in Section 2 saying that by = construction if Master Salt is different that will generate different = keys and common IVs (+ reference to OSCORE)? For example in this = paragraph: In fact, 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, since Master Secret, Sender ID and Recipient ID are the same but Master Salt is different. 5. In a related vein, we do not get into full detail about the cryptographic role played by N1 and N2, so as to make the reader confident that our 64-bit recommendation does provide full Internet-grade security (as opposed to a weakened "IoT" variant). = I'm not specifically concerned, but we may get some reviewers asking for more detail. =20 FP: would it be sufficient to add text along the lines of what you = describe in point 3 above? 6. I am, however, concerned about the exposure to an RFC 3552-style attacker for unprotected authz-info responses. There are two main aspects I'm concerned about: identifier selection and nonce = selection. Letting the server override the client's idea of its own identity = (even when the AS has given the client an identifier!) seems to increase = the risk of a client being tricked into impersonating a different = client, and the stated justification (letting the RS preserve uniqueness) doesn't seem to hold up in our one-AS-per-RS stated scope, where the = AS can equally well do so. Based on what I know right now, it doesn't = feel like we're at the right point on the cost/benefit curve. For the = nonce selection, this comes into play due to the lack of injectivity for = the mapping of initial AS-generated salt, N1, and N2 into the Master = Salt. Specifically, if a client chooses an N1 that's a prefix of some = other N1 that was used, then the attacker can send an "N2" that contains the = tail end of that other N1 plus the actual N2 picked by the server in that other exchange, causing a full nonce collision and having the AS-generated portion be the only difference in Master Salt between security contexts. Using a length prefix for the fields being concatenated provides injectivity and thwarts this type of attack. =20 FP: Concerning identifier selection: after a number of points raised = (here and in following points), I do believe that the mechanism of = letting the RS pick the identifier of the client is not worth the = additional complexity. So I propose we revert that, and go back to AS = MUST pick the clientId, the clientId MUST be included in the token. This = will only add some considerations about the scenario has = several-AS-per-RS, in which case these AS need to be synchronized on = clientIds they give out.=20 About nonce selection: we will define N1 and N2 as CBOR bstr, so that = the length prefix will be included. 7. There are a few places where I'm not entirely sure how the = protocol flow works for the case where the RS is (re)assigning the clientId; I've tried to note them in the section-by-section comments. =20 FP: Yes, I agree, we missed some of those. As mentioned, I think it = could be solved, but the additional complexity is probably not worth it. On to the section-by-section notes: =20 Section 1 =20 8. I'd suggest noting that this is a symmetric-crypto-based scheme in = some manner (e.g., that the AS is assigning a shared symmetric key used = as the OSCORE master secret), and/or that asymmetric PoP semantics are not = possible with this mechanism (or OSCORE in general). FP: OK =20 9. I'd also suggest noting that proof of possession is not done by a = dedicated protocol element, but rather occurs implicitly based on knowledge of = the OSCORE Security Context. (This is essentially analogous to = Kerberos, but a reference is not strictly needed.) We do have a good treatment in toplevel Section 4, but it might be worth saying earlier. =20 FP: OK Section 2 =20 10. [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 = TLS or DTLS MAY be used additionally or instead. =20 Since the client/AS and client/RS profile are supposed to be = completely severable, I don't think we should use "MAY" here; perhaps "but = other protocols (such as TLS or DTLS) can be used as well". =20 FP: OK 11. Once the client has retrieved the access token, it generates a = nonce N1 and posts both the token and N1 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 =3D = application/ace+cbor. =20 Do we want to say explicitly that there is no cryptographic = protection applied for this POST to authz-info? FP: OK (will add a note) =20 12. which contains a nonce N2 in a CBOR map. Moreover, the server concatenates N1 with N2 and appends the result to the Master Salt = in the Security Context (see section 3 of [I-D.ietf-core-object-security]). The RS then derives the = complete Security Context associated with the received token from it plus = the parameters received in the AS, following section 3.2 of [I-D.ietf-core-object-security]. =20 This passage feels strange to me, probably because it seems to use = "Master Salt" to both the portion with and without N1+N2, and also because = it does not introduce "the Master Salt" as a term or some other object that = deserves the definite article. Would it be equivalent to say "Moreover, the = server concatenates the input salt, N1, and N2 to obtain the Master Salt of = the OSCORE Security Context (see section 3 of = [I-D.ietf-core-object-security]" instead? (Though the details may yet change based on later = comments...) Is "from it" the resulting Master Salt? There seems to be a word or two missing in "the parameters received = in the AS". (Presumably these parameters are contained in the token?) =20 FP: OK. Yes,that would be equivalent. Yes, "From it" referred to the = Master Salt (the input salt concatenated with N1 and N2). Yes, it's = missing "received in the access token from the AS". 13. After receiving the nonce N2, the client concatenates it with = N1 and appends the result to the Master Salt in its Security Context = (see section 3 of [I-D.ietf-core-object-security]). The client then derives the complete Security Context from the nonces plus the parameters received from the AS. =20 Similarly, IIUC we should be able to word this so that the "Master = Salt" is unique (and includes the nonces), as opposed to having it apparently = refer to both the pre- and post-nonce-includion strings. Are these "parameters" received from the AS in the token response? =20 FP: OK. Yes, they are. 14. Finally, the client sends a request protected with OSCORE to = the RS. If the request verifies, then this Security Context is stored in = the server, and used in the response, and in further communications = with the client, until token expiration. This Security Context is discarded if the same token is re-used to successfully derive a = new Security Context. =20 The conditional on storing the Security Context only if the request verifies reads oddly to me, as the RS seems to have needed to store = some amount of security context information for the period betweeen = receiving the token and receiving the authenticated request, as a prerequisite = to being able to verify the request. Also, is this security context discarded if a new token from the = same client is successfully used? FP: "Storing" is probably not clear enough, the point is that only after = the request passes verification the server marks this security context = as "valid" for this client. I'd love suggestions on how to make this = clearer. Yes, the security context is discarded if a new token (or a = valid old one) is successfully used. Is anything missing here? =20 15. The use of random nonces during the exchange prevents the = reuse of AEAD nonces and keys with different messages, in case of re- derivation of the Security Context both for Clients and Resource Servers from an old non-expired access token, e.g. in case of = re-boot of either the client or RS. In fact, by using random nonces as = part =20 This sentence is pretty long and a little hard to parse. I'd = suggest something more like: =20 % The use of random nonces during the exchange prevents the reuse = of % an AEAD nonces/key pair for two different messages. This = situation % might occur when client and RS derive a new Security Context from = an % existing (non-expired) access token, as might occur when either = party % has just rebooted. [...] =20 FP: OK I'd also consider s/In fact/Instead/ since we are contrasting the previously described hypothetical (bad) scenario with what actually happens. =20 FP: OK 16. of the Master Salt, the request to the authz-info endpoint = posting the same token results in a different Security Context, since = Master Secret, Sender ID and Recipient ID are the same but Master Salt = is different. Therefore, the main requirement for the nonces is = that =20 nit: [more usage of "Master Salt" for pre- and post-nonce forms] I'd also suggest to s/since/since even though the/ (and the = s/but/the/ needed to fix up the end of the sentence). FP: OK (reformulation already fixed in PR) =20 I also want to check my understanding: this "different Security = Context" is still going to use the same identifiers for the endpoints, and will = just have different keys/IVs/etc? This would tie in to the (later) = recommendation to have such a new Security Context completely replace the old one, = since otherwise we'd have to resort to trial decryption to determine which Security Context to use for processing a given message. =20 FP: Yes, it would use the same identifiers. Typically, the old security = context would get discarded when the new one is validated. Applications = could still decide to keep more than one context, and in that case yes, = they'd have to rely on trial decryption, but that is not the goal of = this document. 17. 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. =20 I guess the focus on "good amount of randomness" is trying to = emphasize that we merely need to avoid a single node accidentally producing = the same value, as opposed to a stricter property of unguessability by = an on-path attacker? Or is unguessability also needed when the = attacker can delay traffic? =20 FP: Yes, that is correct (about the single node). We do not think = unguessability is needed. Do you think it should? Section 3 =20 18. Section 3.2 of [I-D.ietf-core-object-security] defines how to = derive a Security Context based on a shared master secret and a set of = other parameters, established between client and server, which the = client receives from the AS in this exchange. The proof-of-possession = key =20 We say that the client gets the OSCORE parameters from the AS in the token response; where do we say how the RS gets the OSCORE = parameters from the AS? =20 FP: Do you mean this sentence from section 4. The client generates a nonce N1 and posts it together with the token that includes the materials provisioned by the AS to the RS.=20 And if not, what are we missing? Section 3.1 =20 19. The client MUST send this POST request to the token endpoint = over a secure channel that guarantees authentication, message integrity = and confidentiality (see Section 5). =20 (The framework already requires this, so we may not need the "MUST" keyword again, though I'm not proposing to remove all mention of the need for these properties.) FP: OK, will remove normative MUST etc for the requirements coming from = the framework. =20 20. An example of such a request, in CBOR diagnostic notation = without the tag and value abbreviations is reported in Figure 2 =20 nit: only the payload is using CBOR diagnostic notation; the headers = are using CoAP notation. FP: Done in PR. =20 21. If the client wants to update its access rights without = changing an existing OSCORE Security Context, it MUST include in its POST = request to the token endpoint a req_cnf object. The req_cnf MUST include = a kid field carrying a CBOR array object containing the client's identifier (assigned in section Section 3.2) and optionally the context identifier (if assigned in section Section 3.2). The = CBOR =20 I'm not sure the best way to write a clear description that includes = the "bstr" framing for "kid". FP: OK, it is missing here that the CBOR array is wrapped in a bstr. I = did miss that the kid is a CBOR bstr and not a byte string. Also, nit: the "assigned" language in the parentheticals feels weird = to me, here. FP: Why? the use of "assigned" was to highlight that that's the value = the AS has set and communicated to the Client. How can we make it = clearer? What's the workflow when the RS has overridden the AS's idea of the clientId? Does the client have to remember the original AS-assigned clientId and use it here instead of the RS-assigned one? FP: Good point, which we did not expand on. Yes, to make this mechanism = work (RS can pick an identifier for the client + AS has already assigned = one) the client would have to remember the original AS-assigned clientID = and use that. Or we should define a mechanism for the client to = communicate the RS-assigned clientId to the AS. This would be necessary = also in case the AS did not assign the clientId at all. After thinking = this through I think this complication makes this RS overwriting the = clientId mechanism not worth having. =20 22. These identifiers can be used by the AS to determine the = shared secret to construct the proof-of-possession token and therefore = MUST identify a symmetric key that was previously generated by the AS = as a shared secret for the communication between the client and the = RS. =20 nit: I suggest s/shared secret to construct/shared secret bound to/ =20 FP: Done in PR. Also, I think the AS will need to use some of the other token = request parameters (e.g., req_aud) in order to determine the client and RS = for which it needs to retrieve the shared PoP key. We might want to = mention that as well. FP: I am not sure that would be needed, in principle. If the client = sends them, then yes, they could be used (and I can add text clarifying = that), but if it doesn't, those identifiers should be enough. =20 23. The AS MUST verify that the received value identifies a = proof-of- possession key and token that have previously been issued to the requesting client. If that is not the case, the Client-to-AS = request =20 nit: It's not clear that we need it to identify a specific token, = just a key. (And in fact for multiple successive access-rights updates, = there will be more than one previous token.) =20 FP: Done in PR. Unrelated, but why would the AS keep more than one = previous token? The "kid" "req_cnf" member in Figure 4's example does not include = the bstr wrapper that draft-ietf-ace-cwt-proof-of-possession suggests is required. FP: correct, kid is missing the bstr wrapper, but req_cnf should be = correct, as it should be a map = (https://tools.ietf.org/html/draft-ietf-ace-oauth-params-11#section-3.1 = defines it having the same structure of "cnf" from = draft-ietf-ace-cwt-proof-of-possession, which in section 3.4 defines it = as a CBOR map). =20 Section 3.2 =20 24. Moreover, the AS MUST provision the following data: =20 It's frequently the case in IETF documents that "provision" is a euphimism for "out-of-band configuration", so if we mean "include in = the token response" it's probably better to say that directly. FP: OK, Done in PR. =20 25. Additionally, the AS MAY provision the following data, in the = same response. =20 When the AS does not do so, how are these parameters determined? =20 FP: Context ID can be omitted and not used in OSCORE. AEAD alg, HKDF = alg, salt and replay window can be omitted and then the default value = would be used in OSCORE. That should be clear from section 4.3, = specifically the sentence: " In case these parameters are omitted, the default values are used as described in section 3.2 of [I-D.ietf-core-object-security]. " Anything else we need to add? 26. The OSCORE_Security_Context is a CBOR map object, defined in Section 3.2.1. The master secret MUST be communicated as the = 'ms' field in the OSCORE_Security_Context in the 'cnf' parameter of = the access token response as defined in Section 3.2 of [I-D.ietf-ace-oauth-params]. The AEAD algorithm MAY be included = as =20 nit: s/in the OSCORE_Security_Context/in the OSCORE_Security_Context field/, I think? FP: Done in PR. Yes it is. =20 27. the 'alg' parameter in the OSCORE_Security_Context; the HKDF algorithm MAY be included as the 'hkdf' parameter of the OSCORE_Security_Context, a salt MAY be included as the 'salt' parameter of the OSCORE_Security_Context, and the replay window = type and size MAY be included as the 'rpl' of the = OSCORE_Security_Context, as defined in Section 3.2.1. =20 I think we want to reword all of these, as I understand what we're = doing to be defining the parameters in which these values are conveyed, if they are conveyed at all. Just saying " MAY be conveyed in " = has the connotation that might alternatively be conveyed in some = other that is not mentioned. The relevant MAY for our purposes is the = one above the list -- "the AS MAY provision the following data". FP: OK. I will remove all the normative MAY and replace them with may. = Would that be sufficient? =20 28. The same parameters MUST be included as metadata of 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_Security_Context structure defined above MUST be placed in = the 'cnf' claim of this token. =20 nit: "metadata of the access token" sounds like it's trying to be a = term of art, but it is not presently used as such. = s/metadata/attributes/ would, IIUC, be more in keeping with OAuth 2.0 tradition. FP: rephrased into "part of the access token" in PR, is that ok? not-nit: the second sentence seems redundant with the second = sentence of the previous paragraph. FP: I do agree there is some redundancy. The previous sentence=E2=80=99s = MUST referred to the master secret and how it MUST be transported = (=E2=80=98ms=E2=80=99 field of =E2=80=98OSCORE_Security_Context=E2=80=99 = in =E2=80=98cnf=E2=80=99), this sentence is about = OSCORE_Security_Context in =E2=80=98cnf=E2=80=99. I suggest removing the = first MUST, as that will be compliant with point 27, removing the = normative MAYs. =20 29. The AS MUST also assign an identifier to the RS (serverId), = MAY assign an identifier to the client (clientId), and MAY assign an identifier to the context (contextId). These identifiers are = then used as Sender ID, Recipient ID and ID Context in the OSCORE = context as described in section 3.1 of [I-D.ietf-core-object-security]. = The couple (client identifier, context identifier) MUST be unique in = the set of all clients on a single RS. Moreover, when assigned, serverId, clientId and contextId MUST be included in the OSCORE_Security_Context, as defined in Section 3.2.1. =20 [Any time we're assigning identities we have to say something about = the privacy properties thereof, or a bunch of reviewers will complain.] FP: OK. What about adding privacy considerations pointing to the privacy = considerations in OSCORE? I feel that should cover it. Is the Recipient ID expected to be stable/persistent for a given RS = as seen by all clients? FP: Not necessarily. nit: "all clients on a single RS" reads oddly to me; maybe s/on/of/? FP: Done in PR. s/on/for nit: I'd suggest to replace "couple" with "tuple" or "pair". FP: Done in PR: "pair". nit: serverId is always assigned by the AS, so the "when assigned" doesn't quite bind properly, grammar-wise. While the clientId is "always assigned" by the time of the Master Secret derivation, this = is just discussing the AS token response, so we can't necessarily = assume it's assigned here, at least with the current protocol spec. FP: Done in PR. I believe this is a formulation problem. Yes the = serverId is always assigned, so it would always be included in the = OSCORE_Security_Context. The point of this sentence was: whenever the AS = assigns a value for the identifier, it also sets the corresponding field = to that value in the OSCORE_Security_Context. I reformulated: The pair = (client identifier, context identifier) MUST be unique in the set of all = clients for a single RS. Moreover, clientId, serverId and (when = assigned) contextId MUST be included in the OSCORE_Security_Context, as = defined in ... This would be consistent with removing the option of = clientId not being included in the OSCORE_Security_Context. =20 OSCORE requires a Sender ID and Recipient ID, but we only have it as optional for the AS to assign the clientId -- what does OSCORE use = as the Sender/Recipient ID when the AS does not assign a clientId? FP: That was the case where the RS MUST assign a clientId, see section = 4.2: =E2=80=9CMoreover, if the OSCORE_Security_Context in the token did not contain a 'clientId' parameter, the RS MUST generate an identifier, unique in the set of all its existing client identifiers, and send it in a 'clientId' parameter in the CBOR map as a CBOR bstr.=E2=80=9C But if we agree on removing this mechanism, this becomes outdated. =20 When certain fields are optional, we typically have to ask whether = it's possible for the two parties to disagree about whether the field is present. IIUC, the OSCORE context derivation procedure includes = enough information to prevent that possibility, but it would be good if = someone would confirm that. FP: That is correct, a number of fields have default values when non = present. Hkdf, alg, salt, contextId, rpl. On the other hand, ms, = clientId and serverId need to be set. =20 30. We assume in this document that a resource is associated to = one single AS, which makes it possible to assume unique identifiers = for each client requesting a particular resource to a RS. If this is = not =20 I feel like this might be more clear if we can frame it in terms of = the AS enforcing the uniqueness of client identifiers (or, if you will, = that we delegate the enforcement thereof to the AS...) =20 FP: OK 31. the case, collisions of identifiers may appear in the RS, in = which case the RS needs to have a mechanism in place to disambiguate identifiers or mitigate their effect. =20 nit: s/appear in/occur at/ FP: Done in PR. nit: s/mitigate their effect/mitigate the effect of the collisions/ FP: Done in PR. =20 32. Note that in Section 4.3 C sets the Sender ID of its Security = Context to the clientId value received and the Recipient ID to the = serverId value, and RS does the opposite. =20 (The way this is written implicitly assumes that both clientId and serverId are received from the AS.) FP: That's right. I would keep as is if we agree on removing the = RS-assigns-identifier mechanism. =20 33. Figure 5 shows an example of such an AS response, in CBOR = diagnostic notation without the tag and value abbreviations. =20 I'd suggest s/such an AS response/an AS token response/ FP: OK =20 34. "access_token" : h'a5037674656d7053656e73 ...' (remainder of access token omitted for brevity)', =20 In addition to the invalid-CBOR-diagnostic-notation-syntax comment, = we also have unbalanced quotes. FP: Right, but this is not valid CBOR diagnostic notation syntax anyway, = do you have a better idea? I do not think it would be useful to have the = full token here. Will remove the unbalanced quote. =20 35. "profile" : "coap_oscore", "expires_in" : "3600", "cnf" : { "OSCORE_Security_Context" : { "alg" : "AES-CCM-16-64-128", "clientId" : b64'qA', "serverId" : b64'Qg', =20 Any reason to prefer b64'qA' over h'a8' which is shorter? FP: No, this is a leftover of some previous example. Will remove b64 = encodings. =20 36. If the client has requested an update to its access rights = using the same OSCORE Security Context, which is valid and authorized, the = AS MUST omit the 'cnf' parameter in the response, and MUST carry the client identifier and optionally the context identifier in the = 'kid' field in the 'cnf' parameter of the token, with the same = structure =20 I think we should be careful about referring to this as "optionally = the context identifier" -- the choice for whether there is a context identifier is made once (at initial issuance), and subsequent usage depends on whether one has been allocated or not. It's not like the = AS can decide at runtime "I gave you a context identifier for your = original security context, but I don't feel like giving it to you again" -- = the derived keys won't match up and it won't be reusable as the same security context. FP: Right, this again is a formulation problem. The optionality comes = from if it has ever been assigned/allocated/set for that security = context. What about reformulating into:=20 , and MUST carry the client identifier and the context identifier (if it was set and = included in the initial access token response byt the AS) in the 'kid' field in the 'cnf' parameter of the token, with the same = structure Also, I'm not sure this is fully defined for the case when the RS overrides the AS's clientId assignment, as the kid array in the = token needs to be the value the RS will know, but the kid in req_cnf needs = to be the one the AS knows, and we don't really define a mechanism for = the AS to be able to do translation from one to the other. =20 FP: Right=E2=80=A6 this is getting complicated. If the client and the RS = both kept track of AS-assigned and RS-assigned clientId, that could = still work. Or if there was a mechanism for the client to communicate to = the AS: =E2=80=9Cthis is the RS-assigned kid, this is the AS-assigned = kid, please talk to me as the former=E2=80=9D. As mentioned, I think = this is getting too complicated and propose removing this mechanism = altogether. 37. defined in Figure 3. These identifiers need to be = provisioned, in order for the RS to identify the previously generated Security Context. =20 nits: there's only one (not "these") identifier in the token, and nothing in the token response; and a similar remark about = "provisioned" as was made above. FP: Here it referred to both clientId and contextId (from the previous = sentence), which are carried in the kid field, so I think = =E2=80=9Cthese=E2=80=9D should be ok. Please correct me if I am wrong. = Ok about provisioned, done in PR. =20 38. Figure 9 shows an example CWT, containing the necessary OSCORE parameters in the 'cnf' claim for update of access rights, in = CBOR diagnostic notation without tag and value abbreviations. =20 { "aud" : "tempSensorInLivingRoom", "iat" : "1360189224", "exp" : "1360289224", "scope" : "temperature_h", "cnf" : { "kid" : b64'qA' =20 I don't think this "kid" is a valid CBOR bstr wrapping the one- or two-element array. FP: OK =20 Section 3.2.1 =20 39. [I-D.ietf-core-object-security]). The OSCORE_Security_Context = object can either be encoded as JSON object or as CBOR map. In both = cases, =20 nits "a JSON object", "a CBOR map". FP: Done in PR. =20 40. defined below. All parameters are optional. Table 1 provides = a summary of the OSCORE_Security_Context parameters defined in this section. =20 They're optional to appear in the OSCORE_Security_Context object = that's included in a "cnf" value, but not necessarily optional for OSCORE = to be usable. What do we do for OSCORE when any given parameter is not present in this structure? (Also, doesn't the AS always have to = provide things like 'ms' and 'serverId'?) FP: This is just the structure definition, which is aimed to be more = general than just for this spec. For example, this could be reused to = send only a part of these parameters, for example if only the salt + = identifiers need to be updated. Yes, that is correct, not all parameters = are optional when used in this profile, as mentioned in a previous = point. ms, serverId are not optional. In an OSCORE Security Context: = master secret, sender Id and recipient Id are not optional. Section 4.3 = describes what happens if any of the parameters is not present: =E2=80=9CIf any of the expected parameters is missing (e.g. any of the mandatory parameters from the AS, or the 'clientId', either received from the AS or in the 2.01 (Created) response from the RS), 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.=E2=80=9D =20 41. | hkdf | 4 | bstr / int | COSE | OSCORE = HKDF | | | | | Algorithm | value = | | | | | Values | = | | | | | (HMAC-based) | = | =20 Should be tstr, not bstr, right? FP: Yes, OK. =20 Also, why do we need the string form of either hkdf or alg? More possibilities makes the decoder more complicated and increases the attack surface. FP: because a COSE algorithm can be registered as a string (see = https://tools.ietf.org/html/rfc8152#section-16.4 = =E2=80=9CValue=E2=80=9D). =20 42. | rpl | 8 | bstr / int | | OSCORE = Replay | | | | | | Window Type = | | | | | | and Size = | =20 Should just be bstr (not int), right? =20 FP: Yes. OK. 43. hkdf: This parameter identifies the OSCORE HKDF Algorithm. = For more information about this field, see section 3.1 of [I-D.ietf-core-object-security]. The values used MUST be registered in the IANA "COSE Algorithms" registry and MUST be HMAC-based HKDF algorithms. The value can either be the = integer =20 It's a little unfortunate that we basically are relying on "I know = it when I see it" for determining which algorithms are HKDF algorithms. FP: Agreed, but we don=E2=80=99t really have another way to say this. If = you or COSE experts (Jim) have any idea please let us know. =20 Also, "HKDF" expands to "HMAC-based Extract-and-Expand Key = Derivation Function", i.e., is definitionally HMAC-based. So this should be reworded to reflect the actual intent. FP: Right, that is because COSE also defines HKDF using AES-MAC, see = Table 12 of RFC8152, so we needed to specify that only HMAC-based can be = used. =20 44. alg: This parameter identifies the OSCORE AEAD Algorithm. = For more information about this field, see section 3.1 of [I-D.ietf-core-object-security] The values used MUST be = registered in the IANA "COSE Algorithms" registry and MUST be AEAD algorithms. The value can either be the integer or the text =20 Similarly, this seems to be "I know it when I see it". =20 FP: Yes. 45. 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 [I-D.ietf-core-object-security]. In JSON, the "contextID" = value is a Base64 encoded byte string. In CBOR, the "contextID" = type is bstr, and has label 7. =20 Do we need to forbid present-but-empty contextIds in order to avoid cryptographic collision with absent-contextId? FP: The field being present but empty (i.e. value is the empty byte = string) is not the same as absent, in OSCORE. So we do not need to = forbid that. =20 46. rpl: This parameter is used to carry the OSCORE value, = encoded as a bstr. This parameter identifies the OSCORE Replay Window Size = and Type value, which is a byte string. For more information = about this field, see section 3.1 of = [I-D.ietf-core-object-security]. In JSON, the "rpl" value is a Base64 encoded byte string. In CBOR, the "rpl" type is bstr, and has label 8. =20 I tried to follow the reference, but I couldn't really find a description of the encoding for this as a byte string (especially noteworthy since we claim that it represents both size and type). (Relatedly, I'm not sure why it's allowed to be either bstr or int.) =20 FP: Right, this is an old reference, where we actually gave a default = encoding for rpl, I believe. Now this is entirely up to the application. = I would keep this as bstr and specify that it is any format wrapped in a = bstr. Also I need to fix a couple of mistakes: =E2=80=9COSCORE value=E2=80=9D = is wrong; =E2=80=9CReplay Window=E2=80=9D and not "Size and Type". Also, = I think we need to define a new IANA registry for rpl with 0 as default, = so that applications can define their format. Section 4 =20 47. Can we get some CDDL or similar for both C-to-RS and RS-to-C (in = the respective subsections)? =20 FP: I am not sure what you=E2=80=99d like to see in CDDL in this = subsection, could you expand? 48. I'd naively expect a section titled "Client-RS Communication" to = include some discussion of normal protected OSCORE request/response pairs = once the security context is fully established, but this initial section basically only talks about the authz-info interaction and disclaims = that the subsections will cover anything else. FP: Ok, will add some introductory text about the OSCORE security = context being used of future OSCORE protected communication. =20 49. 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 posts it together with the token = that includes the materials provisioned by the AS to the RS. The RS = then derives a nonce N2 and use Section 3.2 of =20 nits: "provisioned" again, and the RS is going to be generating a = nonce from scratch, not deriving one from ... anything else, really. FP: Done in PR. =20 50. [I-D.ietf-core-object-security] to derive a security context = based on a shared master secret and the two nonces, established between = client and server. =20 (The shared master secret is part of what the AS provisions^Wgives = to the RS, right?) FP: Yes, correct. Actually here it is also the clientId, serverId and = contextId (if any) that are used for deriving the OSCORE context. =20 51. Note that the proof-of-possession required to bind the access = token to the client is implicitly performed by generating the shared = OSCORE Security Context using the pop-key as master secret, for both = client and RS. An attacker using a stolen token will not be able to generate a valid OSCORE context and thus not be able to prove possession of the pop-key. =20 It may be worth saying something roughly equating "proof of = possesion performed by the RS" and "the RS authenticating itself to the = client", since there is not an external action for server authentication. Also, ISTR getting some pushback on a different document that talked about an attacker with a "stolen token", as something that can steal = a token from the client's local storage might also steal the = associated key. I forget if we ended up changing to some other phrasing or = not, though :( FP: Ok, will rephrase to =E2=80=9Cthe RS authenticating itself=E2=80=9D = instead of =E2=80=9Cpop performed by the RS=E2=80=9D. Also, what about = using eavesdrop here instead? =20 Section 4.1 =20 52. The client MUST generate a nonce N1 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. The = client =20 Why 64 instead of 128? I know that 128 is enough without having to think about it; for 64 we have to be clear about what role the nonce = is serving. =20 FP: We brought this up in the wg and everybody seemed to be ok with 64. = We can go up to 128 if you think it=E2=80=99s better. Also consider that = OSCORE appendix B2 has a similar setting and does some considerations = about that, mentioning that "typically nonces of at least 8 bytes will = be used". Maybe add a reference? https://tools.ietf.org/html/rfc8613#page-72 I brought it up as one of = the points the wg should agree on. 53. Note that the use of the payload and the Content-Format is = different from what 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 and N1 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 correct CBOR label (e.g., "cwt" for = CWT, "jwt" for JWT) and N1 using the 'cnonce' parameter defined in = section 5.1.2 of [I-D.ietf-ace-oauth-authz]. =20 That's not what the 'cnonce' parameter is for -- 'cnonce' is = protecting the RS against replay, but N1 is protecting the client. I think we = need to use a different name (and maybe define some integer map label values?) for this authz-info POST body. FP: As mentioned, this was raised as an open point and ok by the wg (and = particularly Ludwig and Jim). =20 54. The access token MUST be encrypted, since it is transferred = from the client to the RS over an unprotected channel. =20 This is probably worth stating in Section 3.2 as well, where we = discuss the AS-to-C token response in more detail. =20 FP: OK. 55. Note that a client may be required to re-POST the access = token, since an RS may delete a stored access token, due to lack of memory. =20 I'd suggest using the phrase "at any time" and noting that the = client will detect this by receiving an AS Request Creation Hints message = since the RS treated the request as an Unauthorized Resource Request, = perhaps: =20 % Note that a client may be required to re-POST the access token in % order to complete a request, since an RS may delete a stored = access % token at any time, for example due to all storage space being % consumed. This situation is detected by the client when it = receives % an AS Request Creation Hints response. =20 FP: OK. 56. Payload: { "access_token": h'a5037674656d7053656e73 ...' (remainder of access token omitted for brevity)', "cnonce": h'018a278f7faab55a' } =20 This does not appear to be using either a "cwt" label or "jwt" = label, as the second paragraph of the section would have us using. FP: OK. Will use "cwt". =20 Section 4.2 =20 57. token. If the token is valid, the RS MUST respond to the POST request with 2.01 (Created). If the token is valid but is = associated =20 We probably don't need to repeat the normative requirements from the core framework with normative keywords again. FP: OK. =20 58. to claims that the RS cannot process (e.g., an unknown scope), = or if any of the expected parameters in the OSCORE_Security_Context is =20 Hmm, "associated to claims that the RS cannot process" sounds like = we're telling the RS to abort if the token includes any unrecognized = claims, which IIUC is at odds with the OAuth 2.0 philosophy of ignoring unrecognized parameters. (Hopefully someone will correct me if I'm misremembering that.) FP: This paragraph is meant to mirror what specified in 5.8.1.1 of = ace-oauth-authz: If the claims cannot be obtained the RS MUST discard the token and, in case of an interaction via the authz-info endpoint, return an error message with a response code equivalent to the CoAP code 4.00 (Bad Request). Next, the RS MUST verify claims, if present, contained in the access token. Errors are returned when claim checks fail, in the order of priority of this list: =20 59. missing (e.g. any of the mandatory parameters from the AS), or = if any =20 nit: comma after "e.g.". FP: Done in PR =20 60. Additionally, the RS MUST generate a nonce N2 very unlikely to = have been previously used with the same input keying material, and = send it within the 2.01 (Created) response. The payload of the 2.01 (Created) response MUST be a CBOR map containing the 'cnonce' parameter defined in section 5.1.2 of [I-D.ietf-ace-oauth-authz], = set to N2. This profile RECOMMENDS to use a 64-bit long random = number as nonce. Moreover, if the OSCORE_Security_Context in the token did = not =20 As above, we need to use a different name than 'cnonce', as it's performing a different role (this time, contributing entropy to the master secret). (Also, if we change our recommendation about nonce length above we should do so here as well, of course.) =20 FP: OK, pending wg agreement, and OK. 61. contain a 'clientId' parameter, the RS MUST generate an = identifier, unique in the set of all its existing client identifiers, and = send it in a 'clientId' parameter in the CBOR map as a CBOR bstr. The RS = MAY generate and send a 'ClientId' identifier even though the OSCORE_Security_Context contained such a parameter, in order to guarantee the uniqueness of the client identifier. The RS MUST = use =20 I'm not sure I understand the case where the AS wouldn't be able to guarantee uniqueness of ClientId, and wonder if we could simplify by always having the AS make ID assignment. Is there some more background/usage scenarios here that I'm missing? =20 FP: No that's it. The case I was trying to cover is having several AS = cover the same resource at the same RS. Then we would have to have them = synchronized for uniqueness of ClientId. But yes. Agree on removing this = mechanism. 62. When receiving an updated access token with updated = authorization information from the client (see section 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 for the RS to keep track of = authorization information for a given client. =20 [this same recommendation is already in the core framework] =20 FP: OK, will remove normative text and reference framework. Section 4.3 =20 63. the 'clientId' 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 =3D salt | N1 | N2, where | denotes = byte string concatenation, and where salt was received from the AS in Section 3.2. The client MUST set the Master Secret and Recipient = ID =20 I think it's general best practice to use an injective mapping of = the inputs to the Master Salt value (i.e., length-prefixes for the various = fields, since there are no reserved octet values). FP: OK, using CBOR encoded bstr (or b64 if JSON is used) should fix = that. =20 64. from the parameters received from the AS in Section 3.2. The = client MUST set the AEAD Algorithm, ID Context, HKDF, and Replay Window = from the parameters received from the AS in Section 3.2, if present. = In case these parameters are omitted, the default values are used as described in section 3.2 of [I-D.ietf-core-object-security]. The =20 Ah, okay; I'd asked about default values earlier. That said, if = stock OSCORE ever changes the defaults we'd have to come up with a compatibility = story for communication between old/new nodes. =20 FP: Yes. Maybe adding a version number to this context structure? I = think this is a good idea. 65. client MUST set the Sender ID from the 'clientId in the 2.01 (Created) response, if present; otherwise, the client MUST set = the Sender ID from the parameters received from the AS in Section = 3.2. =20 [As written, this has the clientId from the RS take precedence over = the one from the AS when both are present. I understand that the claimed justification is for the RS to be able to enforce clientId = uniqueness, but it still feels risky, since the value from the RS is unauthenticated.] FP: Let's remove this mechanism. =20 66. If any of the expected parameters is missing (e.g. any of the mandatory parameters from the AS, or the 'clientId', either = received from the AS or in the 2.01 (Created) response from the RS), 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. =20 I think this means "restart at the AS" but it's probably worth being = very explicit about it. FP: Yes, OK will clarify. Also, is there anything to be said about rate-limiting/backoff for = persistent missing parameters? FP: OK, will add a sentence about that. =20 67. 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 this order: Master = Salt =3D salt | N1 | N2, where | denotes byte string concatenation, = and =20 [It might be worth breaking this computation off into a standalone = piece of text that applies to both C and RS, including the edits for = injectivity.] =20 FP: OK 68. where salt was received from the AS in Section 4.2. The RS = MUST set the Master Secret, Sender ID and Recipient ID from the = parameters, received from the client in the access token in Section 4.1 after =20 nit: I'd place the emphasis more on "in the access token" or even = "from the AS" rather than "from the client" -- the RS/AS preestablished = relationship is what authenticates these values. FP: Done in PR: "from the AS forwarded by the client". =20 69. validation of the token as specified in Section 4.2. The RS = MUST set =20 Does Section 4.2 really say much about validation other than "RS = MUST verify the validity of the token"? FP: well, that and points to 5.8.1 of ace-oauth-authz. I pointed to the = framework not to duplicate the reference, but we can do that if you = think it=E2=80=99s best. =20 70. [I-D.ietf-core-object-security]. After that, the RS MUST = derive the complete Security Context following section 3.2.1 of [I-D.ietf-core-object-security], and MUST associate this Security Context with the authorization information from the access token. =20 side note: it's sometimes useful as a rhetorical device to have a = discussion of the abstract data model the RS uses -- in this case, that it = maintains a collection of Security Contexts with associated authorization = information, for all the clients that it's currently communicating with, and that = the authorization information is policy that's used as input to = processing requests from those clients. Otherwise, this text about "MUST = associate" can be a bit vague to the reader. FP: OK, will add this clarification in this section. =20 71. The RS then uses this Security Context to verify the request = and send responses to C using OSCORE. If OSCORE verification fails, error =20 (nit?) what is "the request"? I don't think we've talked about a = specific OSCORE request yet, so this would probably be better if talking = about generic incoming requests from a given client. =20 FP: Done in PR: "verify requests and sends responses". 72. responses are used, as specified in section 8 of [I-D.ietf-core-object-security]. 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. =20 nit: I suggest "MUST respond with an unprotected [...] error message = to requests received that correspond to a security context with an = expired token" to tie it back to which requests are affected. FP: Done in PR. =20 73. If the exchange was an update of access rights, i.e. a new = Security =20 nit: comma after "i.e.". =20 FP: Done in PR. 74. Context was derived from a client that already had a Security = Context in place, the is RECOMMENDED to delete the old Security Context = after OSCORE verification and verification of access rights succeed. = The RS MUST delete the Security Context if it deletes the access = token associated to it. =20 I'm not sure I understand what the workflow is, here -- I assume = that the deletion of the old security context occurs after a successful = update via the authz-info endpoint (as opposed to some particular = OSCORE-protected request), but I don't know what "verification of access rights" = could be performed at that time. Aren't access rights mostly tied to a = specific operation, or is this just supposed to be a more generic = audience/scope check? FP: The RS deletes the old token and the old security context only after = successfully processing a request from the client, using the new token = and security context. That includes OSCORE verification and also access = rights verification, like any normal request. Is that not clear? How to = make it clearer? =20 Section 4.4 =20 75. The RS MUST follow the procedures defined in section 5.8.2 of [I-D.ietf-ace-oauth-authz]: if an RS receives an OSCORE-protected request from a client, then the RS processes it according to [I-D.ietf-core-object-security]. If OSCORE verification = succeeds, and the target resource requires authorization, the RS retrieves = the =20 nit(?): is it appropriate to say "requires additional authorization" = (over the implicit authorization given to any authenticated client)? I'm = not sure if that would be confusing or not. =20 FP: I would think this is more confusing than clarifying because we = don=E2=80=99t talk about implicit authorization in this document. We can = make this change if other people agree that this formulation is better. 76. authorization information from the access token associated to = the Security Context. The RS then MUST verify that the authorization information covers the resource and the action requested. =20 In the vein of my previous note about an abstract data model, we may = not want to be overly prescriptive about "retrieves [...] from the access = token". Per-request introspection is allowed, as is caching the = authorization information in a non-token local datastore. FP: Ok, I understand but I am not sure how to implement this comment. = =E2=80=9CRetrieve=E2=80=9D may be misinterpreted, but in my mind it can = mean both by looking up caching info as well as introspecting. How to = make this clearer? I'd also consider rephrasing to "MUST verify that the resource and = action requested are authorized", since "covers" is perhaps a little vague. =20 FP: OK 77. The response code MUST be 4.01 (Unauthorized) in case the = client has not used the Security Context associated with the access token, = or if RS has no valid access token for the client. If RS has an access =20 The causality here seems a bit weird; how would the RS know what = token was intended just from an OSCORE request that's using a random or = different security context? FP: The RS needs to keep this association between Security Context and = token. This first section covers the case where the client is using a = sec ctx not associated to any token or where that sec ctx was not used = before (so the full OSCORE setup did not go through). Different = (=E2=80=9Cvalid=E2=80=9D) security context associated to a token is = covered in the next section. Is there anything I am missing here? =20 78. token for the client but not for the resource that was = requested, RS MUST reject the request with a 4.03 (Forbidden). If RS has an = access =20 I'd suggest rephrasing this to be in terms of authorization rather = than "token for X", perhaps as "if the RS has an access token for the = client but no actions are authorized on the target resource" FP: OK =20 79. token for the client but it does not cover the action that was requested on the resource, RS MUST reject the request with a 4.05 (Method Not Allowed). =20 Similarly, perhaps "but the requested action is not authorized". FP: OK =20 Also, don't both of these descriptions have high overlap with = Section 5.8.2 of the core framework? Is it necessary to reiterate those behavior specifications? FP: Yes, this whole second paragraph re-iterates that section. We can = remove it, the only thing left will be to specify that = =E2=80=9Cperformed proof-of-possession=E2=80=9D =3D =E2=80=9Chaving an = OSCORE security context established=E2=80=9D =20 Section 5 =20 80. Thank you for clearly stating that the OSCORE security contexts = between RS/AS and C/AS must be established independently of any of the mechanisms = defined in this document, and that the protocols used for the C/RS, C/AS, = and RS/AS steps can be selected independently. FP: Good that it's clear. =20 81. Furthermore the requesting entity and the AS communicate using = OSCORE ([I-D.ietf-core-object-security]) through the introspection = endpoint as specified in section 5.7 of [I-D.ietf-ace-oauth-authz] and = through the token endpoint as specified in section 5.6 of [I-D.ietf-ace-oauth-authz]. =20 I'm not entirely sure what this sentence is trying to say -- it = comes across a little bit as saying that when this document is in use, the = indicated interactions also use OSCORE, but that of course can't be what's = actually intended. Perhaps just saying that the behavior of the = introspection endpoing is specified in section 5.7 of [framework] and that of the = token endpoint is specified in section 5.6 of [framework] would suffice?'' FP: No, this sentence wanted to add to the previous (=E2=80=9Cif OSCORE = is used=E2=80=9D), and just point to the framework=E2=80=99s section for = the specific behaviours. Will rephrase. =20 Section 6 =20 82. o the client receives a number of 4.01 Unauthorized responses = to OSCORE requests using the same security context. The exact = number needs to be specified by the application. =20 Is this a global counter or does it get reset by a successful OSCORE response? FP: I would say this gets reset by a successful OSCORE response. But = probably the application would have to define that as well. Do we need = to add any text about this? =20 83. o the client receives a new nonce in the 2.01 (Created) = response (see Section 4.2) to a POST request to the authz-info = endpoint, when re-posting a non-expired token associated to the existing context. =20 Why is "non-expired" specifically relevant? FP: because if it=E2=80=99s expired the RS will not accept that token. = This was just for clarification. What about adding a parenthesis =E2=80=9C(non-expired)=E2=80=9D? =20 84. The RS MUST discard the current security context associated = with a client when: =20 o Sequence Number space ends. =20 o Access token associated with the context expires. =20 nit: we should make the grammar of the list elements parallel to the = client's list, so "the Sequence Number space ends." and "the access token = associated with the context expires". FP: Done in PR. =20 Section 7 =20 85. We talk about both nonces as needing to be "very unlikely to have = been previously used", and it might be worth trying to quantify that = (e.g., "chance of inadvertent collision less than 2^-32"). =20 FP: This is hard to quantify in a general case. But we can add some text = about avoiding inadvertent collisions. 86. As alluded to in my high-level point, we should have more = discussion of the consequences of the authz-info exchange being completely unprotected. FP: Let's discuss that in the point above. =20 87. a secure binding between the request and the response(s). = Thus the basic OSCORE protocol is not intended for use in = point-to-multipoint communication (e.g. multicast, publish-subscribe). Implementers = of =20 nit: comma after "e.g.". FP: Done in PR. =20 88. provoke re-use. If that is not guaranteed, nodes are still susceptible to re-using AEAD nonces and keys, in case the = Security Context is lost, and on-path attacker replay messages. =20 This text is talking about AEAD nonces, but the nonces (and 64-bit recommendation) previously discussed are the nonces used in the = Master Salt (and thus Master Secret) calculation; we don't really talk about = AEAD nonces specifically anywhere in the document, other than to point out the = risk of (nonce, key) reuse. IIUC, vulnerable nodes would need to reuse both = the N1 or N2 values defined in this spec as well as the OSCORE partial = IV in order to collide the AEAD (nonce, key) pair (noting that both key = and common IV are influenced by the Master Salt). That said, if the N1 = generation is flawed it seems quite plausible that PIV generation is similarly = flawed, so we are right to document the concern. Also, the grammar here is a little bit weird, so perhaps a rewording = to: =20 % provoke re-use. If that is not guaranteed, nodes are % susceptible to re-use of AEAD (nonces, keys) pairs, especially = since an on-path % attacker can cause the client to use an arbitrary nonce for = Security % Context establishment. Even partial loss of Security Context = information % can allow an on-path attacker to replay messages. =20 though I'm not entirely sure I understand which replay scenarios you = had in mind. =20 FP: I think the last sentence in your rewording is partially changing = the intent of the paragraph. Partial loss does not allow attacker to = replay messages; what was meant by that is that, if the context is lost = (think reboot without use of persistent memory, where partial IV could = reset to previously used IVs, and node=E2=80=99s nonce resets to = previously used nonce) and at the same time the attacker replays an old = message (so second nonce is previously used too), that creates the = problem. I would just remove the last sentence of your reworded = paragraph and would be fine with that. 89. This profiles recommends that the RS maintains a single access = token =20 nit: "This profile" singular. =20 FP: Done in PR. 90. Also, tokens may contradict each other which may lead the = server to enforce wrong permissions. If one of the access tokens expires =20 Could you give me an example of the contradiction scenarios? I see = the "common" case as being roughly "Token T1 gives access to the set X = of resources and token T2 gives access to a partially disjoint set Y of resources", but I don't know that such a scenario would be = considered a "conflict". To get a conflict I'd expect more like "token T1 = indicates that access to X is to be denied, but token T2 indicates that access to X = is to be allowed" with some sort of explicit negative ACL, but I don't think = OAuth really has a concept of negative ACL. FP: No, I meant what you describe as the common case. The contradiction = coming from the fact that one token would give access to a set X of = resource that the other token would not give access to. A server = implementation might check only one token, which could lead to wrong = permissions. Do we need to say anything else here? =20 Section 8 =20 91. There might be a few more privacy considerations worth = mentioning: =20 - the token is sent in the clear to the authz-info endpoint, so if a = single token is used with multiple audiences or RSes, a client that uses = the same token from multiple locations can be tracked/correlated by the = access token's value. FP: OK - the nonces exchanged in the authz-info exchange are also sent in = the clear, so using random nonces is best for privacy (as opposed to, e.g., a = counter, that might leak some information). FP: OK - the identifiers clientId/serverId that are created/assigned for = this protocol have some privacy considerations; they overlap a lot with = the core OSCORE considerations in terms of the potential privacy = consequences but there might be a little more to say about guidelines for how the identifiers are generated. If I'm reading OSCORE correctly, for = the uses specified in this document only the clientId will actually go on = the wire? FP: that=E2=80=99s right, unless client and server swap roles, in which = case also serverId (acting as client) could go on the wire. I thought = OSCORE should have this covered. What additional details are missing = here? - similarly, there may be considerations for the ID context values. FP: same, referencing OSCORE should cover it, no? =20 Section 9.1 =20 92. o Profile Description: Profile for using OSCORE to secure communication between constrained nodes using the = Authentication and Authorization for Constrained Environments framework. =20 This is the registry for ACE profiles; "using the Authentication and Authorization for Constrained Envirornments framework" feels = redundant. There's also perhaps something to say about defining "coap_oscore" = for all three interaction flows even though the procedures for two of the = three are essentially just "out of the scope of this specification", though = having *some* identifier for "use OSCORE" is probably still useful. =20 FP: Ok, we can remove the last part. About the interaction flows between = nodes, I am not sure what you mean, as by following definition = https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-31#section-5.6.4.3= it is not mandatory for a profile to specify C-AS and RS-AS, those = flows can be out of scope. Am I missing something? Section 9.2 =20 93. name The JSON name requested (e.g., "ms"). Because a core = goal of this specification is for the resulting representations to be compact, it is RECOMMENDED that the name be short. This name = is case sensitive. Names may not match other registered names in = a case-insensitive manner unless the Designated Experts state = that there is a compelling reason to allow an exception. The name = is =20 nit: I'd suggest s/state/determine/ FP: Done in PR =20 94. CBOR label The value to be used to identify this algorithm. = Key map labels MUST be unique. The label can be a positive integer, a =20 nit: s/Key map/Map key/ FP: Done in PR =20 95. negative integer or a string. Integer values between 0 and = 255 and strings of length 1 are designated as Standards Track = Document required. Integer values from 256 to 65535 and strings of = length 2 are designated as Specification Required. Integer values of greater than 65535 and strings of length greater than 2 are designated as expert review. Integer values less than -65536 = are marked as private use. =20 So use of negative integers from -65535 to -1 and positive integers = greater than or equal to 65536 is not defined? FP: OK Right we missed it. We will fix it. =20 I'd also consider listing [I-D.ietf-core-object-security] as an additional reference for the initial entries, since that specifies = the actual semantics of the fields in question. FP: OK =20 Section 9.3 =20 96. "OSCORE_Security_Context" feels like a somewhat long name in = light of the previous commentary about shorter names being preferred. :) =20 FP: Typically this whole name should not be sent when CBOR is used (so = in constrained environments). But we=E2=80=99ll shorten it, what about = "Sec_Ctx"? 97. o Confirmation Method Description: OSCORE_Security_Context = carrying the OSCORE Security Context parameters =20 I'd suggest rewording the description to "parameters for using = OSCORE per-message security with implicit key confirmation" =20 FP: Ok, still would like to keep OSCORE_Security_Context (or whatever = the structure will be called) somewhere in the description. Section 9.4 =20 98. [same suggested rewording] FP: OK =20 Section 9.5 =20 99. Thank you for indicating in which direction the various = considerations should sway the experts' decisions, as opposed to just what the experts = should consider. :) FP: good. =20 100. The IANA registry established in this document is defined as = expert review. This section gives some general guidelines for what the =20 nit: I suggest "defined to use the Expert Review registration = policy". FP: Done in PR =20 101 The zones tagged as private use are intended for testing = purposes and closed environments, code points in other ranges should = not be assigned for testing. =20 nit: comma splice FP: TIL comme splices. Done in PR. =20 102. o Specifications are required for the standards track range = of point assignment. Specifications should exist for specification required ranges, but early assignment before a specification = is available is considered to be permissible. Specifications are =20 side note: this is a little awkward, as RFC 7120 formally does not = allow "early allocations" for the "Expert Review" policy, so there is not = a formal procedure in place to review and expire early allocations that end = up not being needed. It might be worth something to chat with the IANA = table about in Vancouver. =20 FP: Sure, we will check with IANA. We got inspired by (read shamelessly = stole from) COSE here. Section 10.2 =20 103. We might get some sticklers asking for the terminology = references to be made normative, but I'm not concerned about it one way or the other for = now. =20 FP: OK, will keep in mind. Appendix A =20 104. Thank you for assembling this in list form for me. Do we expect to keep this content in the final RFC? If we do, we = should resynchronize to the current list in Appendix C of the framework :) FP: Definitely should resynchronize. Yes I=E2=80=99d like this content = to stay. =20 105. o how/if the authz-info endpoint is protected: Security = protocol above =20 I thought authz-info was fully unprotected, per Section 4.1's "The = authz-info endpoint is not protected, nor are the responses from this = resource." FP: OK, will fix. =20 Thanks, =20 Ben =20 _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace =20 _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Fri Jan 31 03:23:59 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A345120814; Fri, 31 Jan 2020 03:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3Ke3UX9EYSa; Fri, 31 Jan 2020 03:23:54 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2086.outbound.protection.outlook.com [40.107.21.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0F31120127; Fri, 31 Jan 2020 03:23:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TXfEvlYs0d13Ld9b/uchZ2h29BRSmdhb7UxQCcsBHJUzKD/FXMOSautZjl9ChwwjyaMCMgqur0lKpHFQCUDY9Iz+zeIzhxTa0Elbr9ZXQUHDlEGcrrVDrXzqxXguxFQho69dAN5pmuoIDNyDLsRQZrjHQbeBva46wvOeuWFO8v08iXHMWuCRaSQUnZ+wkfafsJSCuGwHUT4kMXBGEKG4VBAG316kPLQNyNHWbuad10lyNus7vRz+CqAd1Lgd734CzsHnnz2kb/ZrYzrv3xM1npOSmKE/AogT/9yjSOocsua+00yupY3WjLT+3rZmX7JOli0vcVUuBQnBnGSHdUkd2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VPwYN7XQcfW655/4/Bw8iESheImCkk8GFHizUtyFceU=; b=QV9djyWKsB3vRXA8l0AR+6RcZ30pzRDamnpDoem+hLpK45aQ7UDNXtRLr9IFBud9RDy2riw4FPEnaCLawZ3X4oGGmbXSv62JfByUkGcfEWsdaQguGWUyqlnEy5Osz7XPk0Bp0UgAxvNKADv3Y2q9AMeuhSpXRgIObn932JolfWj4cwu89+REooiWbzvQvkV+E4LVmloEhXvJn0T8kzuyU6NCzTPYWr4bSGM0UIYCU6FnWuTxSdKNumw/DHL+tF+O9VZmQJ8m5GgE7YKa/qtdkZRSdA27huLkBXru1GdSm+aGdXrBdwCzi87pBM0tmj3h6KlZ+R3f81B7hVmlQ6YnHQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VPwYN7XQcfW655/4/Bw8iESheImCkk8GFHizUtyFceU=; b=idY6TtaPyxaEHcy13DnJQ/tzUmccO34ul1geuJNIHvZFxNHqmThBAvJ9/48AbXvHoB2mYWjvLY3aYZZMw68Gg3Lm6FSmoew6uW2UU7vuPGeameB/j6MnD8DNEk+YJirXRcMtTtCtdxz/uMg7Fxcn9bfuGu9xNTWBfOQM/o/Rg2E= Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (10.165.195.159) by VI1P189MB0270.EURP189.PROD.OUTLOOK.COM (10.165.196.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.27; Fri, 31 Jan 2020 11:23:49 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::3485:ce83:891b:469]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::3485:ce83:891b:469%4]) with mapi id 15.20.2665.027; Fri, 31 Jan 2020 11:23:49 +0000 Received: from [10.8.8.25] (89.187.189.217) by VE1PR08CA0030.eurprd08.prod.outlook.com (2603:10a6:803:104::43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.22 via Frontend Transport; Fri, 31 Jan 2020 11:23:46 +0000 From: Marco Tiloca To: Jim Schaad , "draft-ietf-ace-key-groupcomm-oscore@ietf.org" CC: "ace@ietf.org" Thread-Topic: draft-ietf-ace-key-groupcomm-oscore Thread-Index: AdXUuS1YkeMOHqDuQo661Ct1JSFA6wDb7EgA Date: Fri, 31 Jan 2020 11:23:49 +0000 Message-ID: <9dea28ee-c4c0-40b9-68bc-c78cfad9d40c@ri.se> References: <010b01d5d7c3$47d36ad0$d77a4070$@augustcellars.com> In-Reply-To: <010b01d5d7c3$47d36ad0$d77a4070$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-clientproxiedby: VE1PR08CA0030.eurprd08.prod.outlook.com (2603:10a6:803:104::43) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) authentication-results: spf=none (sender IP is ) smtp.mailfrom=marco.tiloca@ri.se; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [89.187.189.217] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 457f54e4-e555-49fe-c699-08d7a6400b2d x-ms-traffictypediagnostic: VI1P189MB0270: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 029976C540 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(376002)(346002)(396003)(39860400002)(199004)(189003)(478600001)(26005)(8936002)(16576012)(966005)(16526019)(8676002)(316002)(31696002)(110136005)(66946007)(86362001)(186003)(956004)(71200400001)(53546011)(64756008)(66556008)(66476007)(66616009)(66446008)(81156014)(81166006)(66574012)(52116002)(6486002)(5660300002)(44832011)(2616005)(31686004)(4326008)(2906002)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P189MB0270; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ri.se does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IsDBBpzN0fSrtNTBOGgtJqjigf3iP1D4QrNPOQCjwGZ0850XGC/FiL70fwALBlDGNl1XwlVTzdVQtmPqlwxHnTVAa7MeGl26kcJROJiyDIDjSNs98BvroapHf3iZQ7uKLMNE27ZJTRAls2gNvoY6lKjLRGFCHzgusYk6kt0mWa9dqyvAZ9qNi+J5IQBvq6OA2gbfeBsboGA35ktn4f8HNVWwaNN0LH1Yj7XGcUNR2tyhiac9ueUaaVFjuJZF509uuzEl8JDK5v7EZT+7J5XSE4N39JNJ9NbpL3mM4piYGzZYBqmkjhUPWFP1ITqRoQlA8Z6o4NXkKKOY2Bo2j3KdR/3ZiLdOPOBhQ/p8OQl5STmXctGwoQYgTDtBBYU3d2IEd8hu1BZEUTKkuNYLVaAHmQrDIydlBVRyhNhaKPhKJNyBWsnCUuPvawHKqv5KVrF+ii4l/kThunMVkTRGJJFyGv3ejRrh3ezD3Cyw5f0jOjzFPNajsA3guWIR88UsUGElaMvSUb0hgMZLlzR/rUsumw== x-ms-exchange-antispam-messagedata: Go/+t2nytPBFQmLN7ffYcjydNb9Dg/hzDO0/sjFmsGU3Ce9YQFkxUi6odQwGnRRHbRhmLPR0fu3OFeR5FPO1Ma7yWBcFl+xyUKFUPDCK6xnDu8ekZefejUOlEkdhYW2+uZaZW71cvvUSHcOLNMyJew== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="o1tXIBc1u3bqw8HDpngxr0NaEIBA4vtgu" MIME-Version: 1.0 X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 457f54e4-e555-49fe-c699-08d7a6400b2d X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2020 11:23:49.4430 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8BdvI0Dkk0QZ2g5I5KZY08BjY5Zow2ObOWN8Bzl9oH9URU3aFzt2gDyM6tRhFsu3eZKYhwvGaUHAKKwawCfTkQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0270 Archived-At: Subject: Re: [Ace] draft-ietf-ace-key-groupcomm-oscore X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 11:23:57 -0000 --o1tXIBc1u3bqw8HDpngxr0NaEIBA4vtgu Content-Type: multipart/mixed; boundary="kVG1EIeIdcfzW2H8aailJrm1Wg51hKFFy" --kVG1EIeIdcfzW2H8aailJrm1Wg51hKFFy Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Jim, Thanks for these comments! Please, find some replies below. Best, /Marco On 2020-01-31 00:16, Jim Schaad wrote: > This is not a finished review - but I wanted to get it out. > > Jim > > > General - Should the concept of a legal requester be part of the inform= ation > that is transported with the public key? I don't believe that this is > currently done, but would additionally allow for a server to ignore com= ments > from individuals who are not authorized for that role. This can be indicated in the public key, and then the Group Manager indicates this "role" to other group members, when providing them with the public key of the legal requester. However, how can the Group Manager verify that a legal requester is indeed one, as its public key claims? If we stick to raw public keys, this seems not possible as the only thing that the Group Manager really does is verifying possession of the corresponding private key upon joinin= g. This would probably require certificates rather than public keys, as provided in the 'client_cred' parameter upon joining, which is something that ace-key-groupcomm is anyway admitting, while we are just not doing it here. Then, it becomes about trusting the certificate issuer on legitimately claiming that the certificate owner is indeed a legal requester. > > Section 2.2 - must new security parameters be regenerated on each membe= rship > change? If the application really requires forward and backward security, yes. This is further discussed in the first security consideration of Section = 14. Related, more general aspects about this are discussed in the security considerations of ace-key-groupcomm. In particular, the Group Manager may want to enforce a more relaxed policy than "on each membership change", though making some compromise on the continuity of backward and forward security. > > Section 2.2. - Does completion of a group rekeying include confirmed > redistribution before the version number is incremented? I would say no, but regardless it's something to clarify, possibly already in ace-key-groupcomm . Having the Group Manager generated and sent out the new keying material is sufficient to also increment the version number. It is good that the Group Manager can also get confirmation of distribution, mostly for possible individual re-provisioning, possibly up to a maximum number of retries. Worst case, some group members remain behind, will not be able to retrieve a context or decrypt correctly, and will eventually go to the Group Manager to understand the current status, including the latest version number, and get the latest group key material. > > Section 4.2.1 - I think that we are going to need a discussion on a cou= ple > of issues related to the OSCORE half of how these values are going to b= e > created. Pieces of the discussion are: 1. What is the POP her going to= try > and prove. Specifically is timeliness part of the discussion. 2. What= do > we do about token which grants access to multiple topics. Is joining = the > second group considered to be a re-join rather than an original join fo= r the > purposes of this discussion? 3. What are the interactions about cache= d > public keys, when are these ok and how is this communicated to the clie= nt as > a failure? Sure. Some comments on your points for the discussion: 1. Ultimately the POP is about the owned private key used to sign by the joining node. Building this part of the challenge this way ties the challenge itself with the OSCORE context the two peers have. This is the same construction we have in [1] for building a signature challenge, so probably both documents would likely be affected. 2. Tokens covering multiple groups/topics are a next thing to define in ace-key-groupcomm. Adapting this challenge-based POP will follow. As a general case, the client wants to use different public keys in different groups, which would mean providing one POP signature for each key. Then, the N_S challenge can be as follows: --- If the Access Token is posted to /authz-info , the RS returns an array of N_S, i.e. as many as the number X of groups/topics in the 'scope' of the token. Since the client may then upload Y < X public keys (some of which for more than one group), the client should include in the joining request Y signatures, together with the respective used Y N_C nonces and Y N_S nonces of the X provided by the Group Manager. --- If a TLS exporter is used, 'context_value' has to be non empty, e.g. it can include the public key or a hash of it. For simplicity, we may want to have 'context_value' always non empty, i.e. also when only one public key is involved and even in the simple case of one group/topic onl= y. --- In the OSCORE case, HMAC-Hash may take as 'salt' one more concatenated element, e.g. the public key or a hash of it. For simplicity, we may want to have 'salt' always including this additional element, i.e. also when only one public key is involved and even in the simple case of one group/topic only. 3. Cached public keys and how to handle them are discussed later in Section 5. If something goes wrong, the joining process fails and the Group Manager sends error responses as described in Section 4.3. [1] https://tools.ietf.org/html/draft-tiloca-ace-group-oscore-profile-01#sect= ion-3.1 > > Section 4.3 - Does it make sense to return a new rsnoce as part of thes= e > errors? > That's certainly possible, though I am not sure of the advantage, compared to sticking to the first one returned in the response to the Token POST. > --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --kVG1EIeIdcfzW2H8aailJrm1Wg51hKFFy-- --o1tXIBc1u3bqw8HDpngxr0NaEIBA4vtgu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl40Dj8ACgkQ7iZktA5Y 2kOalwf/XUG+ZjpKYPlLAv/HxUe5+FjbiCZczFt3XOU7fp3bE5D79iAww+os5IEO r1MYmcA1aoBffydv1Lr55pF47HQu4R1I+fSS0yQaY0+itBGdCU30GnHFPBBW+D4b wbrJSTAwb7NlRkgdUe0Ez5piExaC7HMAovFfA4kDRgNmmxg+DiVAysPaFs0mHSrX MKGORWSjMVPhfsVF7Fnp5IGdDfF5xPtNSYokEpzNbx3mRx/r1+CJRBfOP78nuMzf o5Ao3e87pqQ9wSmrvSTmeZIpjYloQIcG+C589wzqdkfmCSf2JcUeUIZO+8U3oU0c qsxaCD7eJcxBT9a/AFbU2RTTkVFyZQ== =be1Z -----END PGP SIGNATURE----- --o1tXIBc1u3bqw8HDpngxr0NaEIBA4vtgu-- From nobody Fri Jan 31 07:46:19 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E55D120130; Fri, 31 Jan 2020 07:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnWQLbXarN_c; Fri, 31 Jan 2020 07:46:16 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5532F120921; Fri, 31 Jan 2020 07:46:11 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 31 Jan 2020 07:46:05 -0800 From: Jim Schaad To: 'Marco Tiloca' , CC: References: <010b01d5d7c3$47d36ad0$d77a4070$@augustcellars.com> <9dea28ee-c4c0-40b9-68bc-c78cfad9d40c@ri.se> In-Reply-To: <9dea28ee-c4c0-40b9-68bc-c78cfad9d40c@ri.se> Date: Fri, 31 Jan 2020 07:46:03 -0800 Message-ID: <013701d5d84d$8cdfdb60$a69f9220$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHFG8xRdUfVvrWtM6BhE83phS1mMgCYQ/zgqCGge6A= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] draft-ietf-ace-key-groupcomm-oscore X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 15:46:18 -0000 -----Original Message----- From: Marco Tiloca =20 Sent: Friday, January 31, 2020 3:24 AM To: Jim Schaad ; = draft-ietf-ace-key-groupcomm-oscore@ietf.org Cc: ace@ietf.org Subject: Re: draft-ietf-ace-key-groupcomm-oscore Hi Jim, Thanks for these comments! Please, find some replies below. Best, /Marco On 2020-01-31 00:16, Jim Schaad wrote: > This is not a finished review - but I wanted to get it out. > > Jim > > > General - Should the concept of a legal requester be part of the=20 > information that is transported with the public key? I don't believe=20 > that this is currently done, but would additionally allow for a server = > to ignore comments from individuals who are not authorized for that = role. This can be indicated in the public key, and then the Group Manager = indicates this "role" to other group members, when providing them with = the public key of the legal requester. However, how can the Group Manager verify that a legal requester is = indeed one, as its public key claims? If we stick to raw public keys, = this seems not possible as the only thing that the Group Manager really = does is verifying possession of the corresponding private key upon = joining. This would probably require certificates rather than public keys, as = provided in the 'client_cred' parameter upon joining, which is something = that ace-key-groupcomm is anyway admitting, while we are just not doing = it here. Then, it becomes about trusting the certificate issuer on = legitimately claiming that the certificate owner is indeed a legal = requester. [JLS] I was assuming that the GM could pull this information from the = 'scope' field of the token. > > Section 2.2 - must new security parameters be regenerated on each=20 > membership change? If the application really requires forward and backward security, yes. This is further discussed in the first security consideration of Section = 14. Related, more general aspects about this are discussed in the security = considerations of ace-key-groupcomm. In particular, the Group Manager = may want to enforce a more relaxed policy than "on each membership = change", though making some compromise on the continuity of backward and = forward security. [JLS] My problem is that I consider the secret key different from the = parameters - might be a semantic issue > > Section 2.2. - Does completion of a group rekeying include confirmed=20 > redistribution before the version number is incremented? I would say no, but regardless it's something to clarify, possibly = already in ace-key-groupcomm . Having the Group Manager generated and sent out the new keying material = is sufficient to also increment the version number. It is good that the Group Manager can also get confirmation of = distribution, mostly for possible individual re-provisioning, possibly = up to a maximum number of retries. Worst case, some group members remain behind, will not be able to = retrieve a context or decrypt correctly, and will eventually go to the = Group Manager to understand the current status, including the latest = version number, and get the latest group key material. [JLS] This is how I read the text - please do some clarification > > Section 4.2.1 - I think that we are going to need a discussion on a=20 > couple of issues related to the OSCORE half of how these values are=20 > going to be created. Pieces of the discussion are: 1. What is the POP = > her going to try and prove. Specifically is timeliness part of the=20 > discussion. 2. What do we do about token which grants access to=20 > multiple topics. Is joining the second group considered to be a=20 > re-join rather than an original join for the purposes of this=20 > discussion? 3. What are the interactions about cached public keys,=20 > when are these ok and how is this communicated to the client as a = failure? Sure. Some comments on your points for the discussion: 1. Ultimately the POP is about the owned private key used to sign by the = joining node. Building this part of the challenge this way ties the = challenge itself with the OSCORE context the two peers have. This is the = same construction we have in [1] for building a signature challenge, so = probably both documents would likely be affected. 2. Tokens covering multiple groups/topics are a next thing to define in = ace-key-groupcomm. Adapting this challenge-based POP will follow. As a = general case, the client wants to use different public keys in different = groups, which would mean providing one POP signature for each key. Then, = the N_S challenge can be as follows: --- If the Access Token is posted to /authz-info , the RS returns an = array of N_S, i.e. as many as the number X of groups/topics in the = 'scope' of the token. Since the client may then upload Y < X public keys = (some of which for more than one group), the client should include in = the joining request Y signatures, together with the respective used Y = N_C nonces and Y N_S nonces of the X provided by the Group Manager. --- If a TLS exporter is used, 'context_value' has to be non empty, e.g. it can include the public key or a hash of it. For simplicity, we may = want to have 'context_value' always non empty, i.e. also when only one = public key is involved and even in the simple case of one group/topic = only. --- In the OSCORE case, HMAC-Hash may take as 'salt' one more = concatenated element, e.g. the public key or a hash of it. For = simplicity, we may want to have 'salt' always including this additional = element, i.e. also when only one public key is involved and even in the = simple case of one group/topic only. 3. Cached public keys and how to handle them are discussed later in = Section 5. If something goes wrong, the joining process fails and the = Group Manager sends error responses as described in Section 4.3. [1] https://tools.ietf.org/html/draft-tiloca-ace-group-oscore-profile-01#sect= ion-3.1 > > Section 4.3 - Does it make sense to return a new rsnoce as part of=20 > these errors? > That's certainly possible, though I am not sure of the advantage, = compared to sticking to the first one returned in the response to the = Token POST. [JLS] depends on the "nonce" quality - that is one time only use. Jim > -- Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se From nobody Fri Jan 31 09:54:14 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1A5120827 for ; Fri, 31 Jan 2020 09:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1tox9Q6pnOE for ; Fri, 31 Jan 2020 09:54:11 -0800 (PST) Received: from mail-vs1-f54.google.com (mail-vs1-f54.google.com [209.85.217.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E324120822 for ; Fri, 31 Jan 2020 09:54:11 -0800 (PST) Received: by mail-vs1-f54.google.com with SMTP id g15so4936431vsf.1 for ; Fri, 31 Jan 2020 09:54:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=p25hsPeIAI2q1YJ1YnqSNi9n+qQIcGlehQLOiMDmy7s=; b=NGmOPghjlQSrhiFH4n6kB5i7bYLfrSARH7NZZjVjDFqVdqsF9CBUprnf8/Eb8cHD7n gye8mMhYTmTQkwciOjPC0aZcSu7XzVLnks0oTmjOZFqtg7XN7SP7zOmtN1d8MnimhNYg xVmS4eySc5cBSW/DkQKsxm+JjbDlFlpsMMmc3K46OfPCf/MZ3iQ1ICz6Uo0z+QaiSezA lIIMxXrvPCOCup1mgwGDkogSV5pR0n+JAYsMbHR0B70HxrPSGEoN2EOf9T9wCPL7FUjG foM3OAHmX0M4OCgaBZP9d+tfk3XAKrCGZdMRTOoS+578eBtkUuPulTP9OmfdlJl+hL6B Z57w== X-Gm-Message-State: APjAAAUKBhaQ73DCj8y5yp9sKP3Mcbini2oAxlAJMW9y9/Cb3P9Ozkxa ot4TyAx9NFtxqi/NSuCl4VySUaKAlnbISQ36ljH2D7pDVOM= X-Google-Smtp-Source: APXvYqxQ47Zl7T+Kr23G7HKRUNEcXelDyPK0TIFqdq5Jy2tbsNYpFIihKSjS0bZ1PCJ5q9wkhEzxesfPHh1spUprcVI= X-Received: by 2002:a67:b309:: with SMTP id a9mr7208872vsm.97.1580493250218; Fri, 31 Jan 2020 09:54:10 -0800 (PST) MIME-Version: 1.0 From: Daniel Migault Date: Fri, 31 Jan 2020 12:53:59 -0500 Message-ID: To: Ace Wg Content-Type: multipart/alternative; boundary="000000000000bfd05d059d734209" Archived-At: Subject: [Ace] ACE provisional interim meeting X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 17:54:13 -0000 --000000000000bfd05d059d734209 Content-Type: text/plain; charset="UTF-8" Hi, We agreed to set another provisional interim meeting the last week of February. Please indicate your preferred availability in the doodle, until Wednesday Feb 5. The provisional agenda includes: * draft-ietf-ace-pubsub-profile * draft-ietf-ace-oscore profile * status on drafts discussed today * .... Yours, Daniel [1] https://doodle.com/poll/z6yuqkm49cxss9vn --000000000000bfd05d059d734209 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

We agreed to set ano= ther provisional interim meeting the last week of February. Please indicate= your preferred availability in the doodle, until Wednesday Feb 5.=C2=A0

The provisional=C2=A0agenda includes:
* dr= aft-ietf-ace-pubsub-profile
* draft-ietf-ace-oscore profile=C2=A0=
* status on drafts discussed today
* ....
Yours,=C2=A0
Daniel
=C2=A0
[1]=C2=A0=C2=A0https://doodle.com/poll/= z6yuqkm49cxss9vn
--000000000000bfd05d059d734209-- From nobody Fri Jan 31 10:32:07 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA40120B85; Fri, 31 Jan 2020 10:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c41t5OtUCFeC; Fri, 31 Jan 2020 10:32:03 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2041.outbound.protection.outlook.com [40.107.22.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31ACC120838; Fri, 31 Jan 2020 10:32:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UyboLUeEdPc9SilFx4M/DPe0/iDxFS+FVB7pTTXz1ik8d+pwCvNKBn+cdjlGxx2LOYU+q3sw7a7b/OWyGfgItvlryar9w5wYX7A8B0Hmvobs41YqS4aFIYOWkkBVIcwe8DMHRA4gPgnB4FP1ZYHKHn68XygqBRIRD7VIC+uw7bPY0zlh+q7otqxAkZANRiNxeGehCZHklFUHQlS21r3+abDMhrhuWrHCmtVcodlPlkbFeBZ+6KhQAFpTRQ+nEqYDF/WP/GLRkkwE3n3p5XRsgAmmX2gbY2Uu2tmAm92IoIHrhsHrs8N4LhMU4D+xDoyiO8+1qMw0g2SFJWIc5thRmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AnZ+kt/aWqv1PzzNkKChCay5uT/0I1YxHrZDd8oY+iY=; b=aB/0PekFHtce9BRbcKwYd228rGOx10qxDOskjUIUNuURT1SWEMfaohsx+oWc0kNR1baLKQHRI1NmYKLJKFJR1CCvolHfCy619imV0EUpdtvfGE0ZgEo1Eu7v8YrbMgFH2lkZ50t/xn0NFfxAOQv41IutmRsXPZzWoG9q46vUo72s7MFilprdtaFMIrrF9TlkJoP5cy05vuH11ZU0ZK+oROS2SyC9cpezZIy6NKqj95EMpCH5rt8hxvG3bgeAZ/vBw8wbMYTeSajMYIU410oFNBPbc6OsosQdfJzGoOp+1O4yVZ1MNPS7yf+7akI6LEMU35w6izgSt6iM/3AM7MPpYQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AnZ+kt/aWqv1PzzNkKChCay5uT/0I1YxHrZDd8oY+iY=; b=IOe3KY4RcUrRwqnSleEm+7qZaH2NH2xcsMq0EuXAJJwE+hT4Hm2p99N8hxp7Th5qEoV28GpCGI7YY0PQciD/Wzec7KL/TDkDgj0iWNy/gU0G55V59n59hFB0NK35/bTo1qGVEeypvp2lXwIelKaA4ce11rAguK0sL4KUxepZX7I= Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (10.165.195.159) by VI1P189MB0480.EURP189.PROD.OUTLOOK.COM (10.165.195.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.23; Fri, 31 Jan 2020 18:32:00 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::3485:ce83:891b:469]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::3485:ce83:891b:469%4]) with mapi id 15.20.2665.027; Fri, 31 Jan 2020 18:32:00 +0000 Received: from [10.8.8.25] (89.187.189.217) by VE1PR08CA0034.eurprd08.prod.outlook.com (2603:10a6:803:104::47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.22 via Frontend Transport; Fri, 31 Jan 2020 18:31:59 +0000 From: Marco Tiloca To: Jim Schaad , "draft-ietf-ace-key-groupcomm-oscore@ietf.org" CC: "ace@ietf.org" Thread-Topic: draft-ietf-ace-key-groupcomm-oscore Thread-Index: AdXUuS1YkeMOHqDuQo661Ct1JSFA6wDb7EgAAAkrFIAABcqrgA== Date: Fri, 31 Jan 2020 18:32:00 +0000 Message-ID: <856e7de6-c11d-5ef0-3077-047b10537609@ri.se> References: <010b01d5d7c3$47d36ad0$d77a4070$@augustcellars.com> <9dea28ee-c4c0-40b9-68bc-c78cfad9d40c@ri.se> <013701d5d84d$8cdfdb60$a69f9220$@augustcellars.com> In-Reply-To: <013701d5d84d$8cdfdb60$a69f9220$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-clientproxiedby: VE1PR08CA0034.eurprd08.prod.outlook.com (2603:10a6:803:104::47) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) authentication-results: spf=none (sender IP is ) smtp.mailfrom=marco.tiloca@ri.se; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [89.187.189.217] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 812b2669-c493-4ef1-0244-08d7a67bdc21 x-ms-traffictypediagnostic: VI1P189MB0480: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5236; x-forefront-prvs: 029976C540 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(366004)(346002)(396003)(136003)(189003)(199004)(4326008)(31696002)(81156014)(8936002)(478600001)(81166006)(8676002)(26005)(966005)(110136005)(186003)(16526019)(6666004)(53546011)(316002)(66556008)(66446008)(66946007)(66476007)(2906002)(956004)(16576012)(2616005)(86362001)(66574012)(71200400001)(5660300002)(31686004)(36756003)(66616009)(64756008)(52116002)(44832011)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P189MB0480; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ri.se does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nBuOinWtxRp4jtaRLsJK/NG+sRwqM/tm49hUSc+5JlqAqurZjqAruwKAsz2/Hz0lwLaoGG/G5k9LlAMMdbXbTK8ZBRp+CNNs/D27BWYP7YbWCj0rzunF2yFBMf2wEjRqJWaQyQbNIu0vkhNzX7ocADPVzLRbH/cNbRJWQSSTG+lLEKUf6q2tH3Pn/8SYTiPZ1uASz8neUm8EzRwNmTfYdPJ8mh5xHkHSObu1Zqkr8m/ucLYB/ATYvwOtjGzps9mHKxSVi59Q0+F+X63RMjJ7wHxgWJaVhHts2PAVW6cJaH2kPgH9aUxPm/mrlviNx+CYEVCRM7KmvTHZGYr4BjyaPXErZStcw97jAV9kPZnZNvLrT1Zh4Bfa+s/Aps+8fK7X+L1nL7UNpe30EW2slk/C2b4tftbaB9W3/htMCDnsOdcT50on2aYHbjBiL36N6gFcYGP6x4+LTb3yhY6sp9rguUZ/Y87CGFyQYHGBy9nkys4H2SkPZKg0Yvjq8Fz87TtacBHf46bFPToQYgDrBMJEJA== x-ms-exchange-antispam-messagedata: gd3d3rXsKUmru4VlF/DiWuusbyQAWhv6RipT2QyydFzt/ORcyXf1SotYdXF2nMkp8mwJXDk/0XLkewxwxHXssnzhQ3ncxMyO5zPywUpBAIHl+b21kKRDfhsG+F9uMDOA9QrwgSTGgKhOL0sD560vPg== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="32j9GqaTdoozIDymv0rFZ29HQ3ZP6p6pd" MIME-Version: 1.0 X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 812b2669-c493-4ef1-0244-08d7a67bdc21 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2020 18:32:00.4041 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZolLEW6B7kEb2+MYJFA64fnTNU3GJ/1iBJTsS7V/Zxoun4VxjS7y7BlCx5WgB6lVr8qbhooxEYYSS3f2CsZxCg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0480 Archived-At: Subject: Re: [Ace] draft-ietf-ace-key-groupcomm-oscore X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 18:32:07 -0000 --32j9GqaTdoozIDymv0rFZ29HQ3ZP6p6pd Content-Type: multipart/mixed; boundary="IwdjOLhaTnlGJ6bmf67ZlePwddDiFMEqM" --IwdjOLhaTnlGJ6bmf67ZlePwddDiFMEqM Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Jim, On 2020-01-31 16:46, Jim Schaad wrote: > > -----Original Message----- > From: Marco Tiloca =20 > Sent: Friday, January 31, 2020 3:24 AM > To: Jim Schaad ; draft-ietf-ace-key-groupcomm-o= score@ietf.org > Cc: ace@ietf.org > Subject: Re: draft-ietf-ace-key-groupcomm-oscore > > Hi Jim, > > Thanks for these comments! > > Please, find some replies below. > > Best, > /Marco > > On 2020-01-31 00:16, Jim Schaad wrote: >> This is not a finished review - but I wanted to get it out. >> >> Jim >> >> >> General - Should the concept of a legal requester be part of the=20 >> information that is transported with the public key? I don't believe = >> that this is currently done, but would additionally allow for a server= =20 >> to ignore comments from individuals who are not authorized for that ro= le. > > This can be indicated in the public key, and then the Group Manager ind= icates this "role" to other group members, when providing them with the p= ublic key of the legal requester. > > However, how can the Group Manager verify that a legal requester is ind= eed one, as its public key claims? If we stick to raw public keys, this s= eems not possible as the only thing that the Group Manager really does is= verifying possession of the corresponding private key upon joining. > > This would probably require certificates rather than public keys, as pr= ovided in the 'client_cred' parameter upon joining, which is something th= at ace-key-groupcomm is anyway admitting, while we are just not doing it = here. Then, it becomes about trusting the certificate issuer on legitimat= ely claiming that the certificate owner is indeed a legal requester. > > [JLS] I was assuming that the GM could pull this information from the '= scope' field of the token. Ok, so it should be just about adding one more role to the current valid ones for 'scope', and updating the list of possible role combinations. Then it's up to the policy evaluation at the AS to confirm that a client is indeed a legal requester, and that that ends up in the token. > >> Section 2.2 - must new security parameters be regenerated on each=20 >> membership change? > > If the application really requires forward and backward security, yes. > This is further discussed in the first security consideration of Sectio= n 14. > > Related, more general aspects about this are discussed in the security = considerations of ace-key-groupcomm. In particular, the Group Manager may= want to enforce a more relaxed policy than "on each membership change", = though making some compromise on the continuity of backward and forward s= ecurity. > > [JLS] My problem is that I consider the secret key different from the p= arameters - might be a semantic issue Other than that, the ID Context (Group ID) is also renewed; the Master Salt may be renewed; the used Sender IDs have to remain the same. Maybe we can have here some of the text on this from the first paragraph of https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm-06#section-2= =2E1 > >> Section 2.2. - Does completion of a group rekeying include confirmed=20 >> redistribution before the version number is incremented? > > I would say no, but regardless it's something to clarify, possibly alre= ady in ace-key-groupcomm . > > Having the Group Manager generated and sent out the new keying material= is sufficient to also increment the version number. > > It is good that the Group Manager can also get confirmation of distribu= tion, mostly for possible individual re-provisioning, possibly up to a ma= ximum number of retries. > > Worst case, some group members remain behind, will not be able to retri= eve a context or decrypt correctly, and will eventually go to the Group M= anager to understand the current status, including the latest version num= ber, and get the latest group key material. > > [JLS] This is how I read the text - please do some clarification Yes, will do. > >> Section 4.2.1 - I think that we are going to need a discussion on a=20 >> couple of issues related to the OSCORE half of how these values are=20 >> going to be created. Pieces of the discussion are: 1. What is the POP= =20 >> her going to try and prove. Specifically is timeliness part of the=20 >> discussion. 2. What do we do about token which grants access to=20 >> multiple topics. Is joining the second group considered to be a=20 >> re-join rather than an original join for the purposes of this=20 >> discussion? 3. What are the interactions about cached public keys,=20 >> when are these ok and how is this communicated to the client as a fail= ure? > > Sure. Some comments on your points for the discussion: > > 1. Ultimately the POP is about the owned private key used to sign by th= e joining node. Building this part of the challenge this way ties the cha= llenge itself with the OSCORE context the two peers have. This is the sam= e construction we have in [1] for building a signature challenge, so prob= ably both documents would likely be affected. > > 2. Tokens covering multiple groups/topics are a next thing to define in= ace-key-groupcomm. Adapting this challenge-based POP will follow. As a g= eneral case, the client wants to use different public keys in different g= roups, which would mean providing one POP signature for each key. Then, t= he N_S challenge can be as follows: > > --- If the Access Token is posted to /authz-info , the RS returns an ar= ray of N_S, i.e. as many as the number X of groups/topics in the 'scope' = of the token. Since the client may then upload Y < X public keys (some of= which for more than one group), the client should include in the joining= request Y signatures, together with the respective used Y N_C nonces and= Y N_S nonces of the X provided by the Group Manager. > > --- If a TLS exporter is used, 'context_value' has to be non empty, e.g= =2E > it can include the public key or a hash of it. For simplicity, we may w= ant to have 'context_value' always non empty, i.e. also when only one pub= lic key is involved and even in the simple case of one group/topic only. > > --- In the OSCORE case, HMAC-Hash may take as 'salt' one more concatena= ted element, e.g. the public key or a hash of it. For simplicity, we may = want to have 'salt' always including this additional element, i.e. also w= hen only one public key is involved and even in the simple case of one gr= oup/topic only. > > 3. Cached public keys and how to handle them are discussed later in Sec= tion 5. If something goes wrong, the joining process fails and the Group = Manager sends error responses as described in Section 4.3. > > > [1] > https://tools.ietf.org/html/draft-tiloca-ace-group-oscore-profile-01#se= ction-3.1 > > > >> Section 4.3 - Does it make sense to return a new rsnoce as part of=20 >> these errors? >> > > That's certainly possible, though I am not sure of the advantage, compa= red to sticking to the first one returned in the response to the Token PO= ST. > > [JLS] depends on the "nonce" quality - that is one time only use. We can make it optional for the server to return a new nonce in the error response. If received, the client has to use that latest nonce when building the challenge to sign for the new joining request. Best, /Marco > Jim > > > -- > Marco Tiloca > Ph.D., Senior Researcher > > RISE Research Institutes of Sweden > Division ICT > Isafjordsgatan 22 / Kistag=C3=A5ngen 16 > SE-164 40 Kista (Sweden) > > Phone: +46 (0)70 60 46 501 > https://www.ri.se > > > --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --IwdjOLhaTnlGJ6bmf67ZlePwddDiFMEqM-- --32j9GqaTdoozIDymv0rFZ29HQ3ZP6p6pd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl40cpkACgkQ7iZktA5Y 2kO81AgAq9n/RV+Qz09hsTO18fz3nyf3kV88TB2fKHNEyJL+YDEt2cPYZNzqs5pm ErgpOc5F82VVbmYeH2avF+ZTX3y0fC3Bt8ISOJeFxIN5+oItMLyokunraHIwTjbo Ckgm/VGu2JEpYvM420pBaKzyMYD47HFk8nugLnBBwtqXKHkfmHg4XsaShfnq9Dm6 hG+2XRQ+3yS4RHxYfuDGh/qgJrylE0nAiPyVcGqYmmWCt50eWsJRKoUSL5LC2MGa dI0z6Csbc6Vooo65yrI/i3DDgWnY2o0ZOxvKL3EIN2+fjOBrgfWnoYqL5QY90gHX OjuF9KpnoIp6YsmDZ/tyfRwHzy8p3w== =3pa5 -----END PGP SIGNATURE----- --32j9GqaTdoozIDymv0rFZ29HQ3ZP6p6pd-- From nobody Fri Jan 31 11:06:56 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF392120815; Fri, 31 Jan 2020 11:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SFpaPMtVfNa; Fri, 31 Jan 2020 11:06:52 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1EBB1200F6; Fri, 31 Jan 2020 11:06:51 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 31 Jan 2020 11:06:46 -0800 From: Jim Schaad To: 'Marco Tiloca' , CC: References: <010b01d5d7c3$47d36ad0$d77a4070$@augustcellars.com> <9dea28ee-c4c0-40b9-68bc-c78cfad9d40c@ri.se> <013701d5d84d$8cdfdb60$a69f9220$@augustcellars.com> <856e7de6-c11d-5ef0-3077-047b10537609@ri.se> In-Reply-To: <856e7de6-c11d-5ef0-3077-047b10537609@ri.se> Date: Fri, 31 Jan 2020 11:06:44 -0800 Message-ID: <015201d5d869$95b35020$c119f060$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHFG8xRdUfVvrWtM6BhE83phS1mMgCYQ/zgASMwPMoCiBnPQagEfM8g Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] draft-ietf-ace-key-groupcomm-oscore X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 19:06:55 -0000 -----Original Message----- From: Marco Tiloca =20 Sent: Friday, January 31, 2020 10:32 AM To: Jim Schaad ; = draft-ietf-ace-key-groupcomm-oscore@ietf.org Cc: ace@ietf.org Subject: Re: draft-ietf-ace-key-groupcomm-oscore Hi Jim, On 2020-01-31 16:46, Jim Schaad wrote: > > -----Original Message----- > From: Marco Tiloca > Sent: Friday, January 31, 2020 3:24 AM > To: Jim Schaad ;=20 > draft-ietf-ace-key-groupcomm-oscore@ietf.org > Cc: ace@ietf.org > Subject: Re: draft-ietf-ace-key-groupcomm-oscore > > Hi Jim, > > Thanks for these comments! > > Please, find some replies below. > > Best, > /Marco > > On 2020-01-31 00:16, Jim Schaad wrote: >> This is not a finished review - but I wanted to get it out. >> >> Jim >> >> >> General - Should the concept of a legal requester be part of the=20 >> information that is transported with the public key? I don't believe = >> that this is currently done, but would additionally allow for a=20 >> server to ignore comments from individuals who are not authorized for = that role. > > This can be indicated in the public key, and then the Group Manager = indicates this "role" to other group members, when providing them with = the public key of the legal requester. > > However, how can the Group Manager verify that a legal requester is = indeed one, as its public key claims? If we stick to raw public keys, = this seems not possible as the only thing that the Group Manager really = does is verifying possession of the corresponding private key upon = joining. > > This would probably require certificates rather than public keys, as = provided in the 'client_cred' parameter upon joining, which is something = that ace-key-groupcomm is anyway admitting, while we are just not doing = it here. Then, it becomes about trusting the certificate issuer on = legitimately claiming that the certificate owner is indeed a legal = requester. > > [JLS] I was assuming that the GM could pull this information from the = 'scope' field of the token. Ok, so it should be just about adding one more role to the current valid = ones for 'scope', and updating the list of possible role combinations. Then it's up to the policy evaluation at the AS to confirm that a client = is indeed a legal requester, and that that ends up in the token. [JLS] I just realized we are not talking about the same problem. I was = thinking about propagating the difference between a publisher (client) = and a responder (server) from the key server to the users of the keys. = This would mean that a server would be able to say - but this message is = not authorized to ask me a question, so don't reply (or fail). > >> Section 2.2 - must new security parameters be regenerated on each=20 >> membership change? > > If the application really requires forward and backward security, yes. > This is further discussed in the first security consideration of = Section 14. > > Related, more general aspects about this are discussed in the security = considerations of ace-key-groupcomm. In particular, the Group Manager = may want to enforce a more relaxed policy than "on each membership = change", though making some compromise on the continuity of backward and = forward security. > > [JLS] My problem is that I consider the secret key different from the=20 > parameters - might be a semantic issue Other than that, the ID Context (Group ID) is also renewed; the Master = Salt may be renewed; the used Sender IDs have to remain the same. Maybe we can have here some of the text on this from the first paragraph = of https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm-06#section-2= .1 [JLS] Perhaps we need to have some type of term for the difference = between those items which are "static" over time and those items which = are "dynamic" over time. This might also be a difference in what is = returned on the issue you raised today in the virtual. Jim > >> Section 2.2. - Does completion of a group rekeying include confirmed=20 >> redistribution before the version number is incremented? > > I would say no, but regardless it's something to clarify, possibly = already in ace-key-groupcomm . > > Having the Group Manager generated and sent out the new keying = material is sufficient to also increment the version number. > > It is good that the Group Manager can also get confirmation of = distribution, mostly for possible individual re-provisioning, possibly = up to a maximum number of retries. > > Worst case, some group members remain behind, will not be able to = retrieve a context or decrypt correctly, and will eventually go to the = Group Manager to understand the current status, including the latest = version number, and get the latest group key material. > > [JLS] This is how I read the text - please do some clarification Yes, will do. > >> Section 4.2.1 - I think that we are going to need a discussion on a=20 >> couple of issues related to the OSCORE half of how these values are=20 >> going to be created. Pieces of the discussion are: 1. What is the=20 >> POP her going to try and prove. Specifically is timeliness part of=20 >> the discussion. 2. What do we do about token which grants access to = >> multiple topics. Is joining the second group considered to be a=20 >> re-join rather than an original join for the purposes of this=20 >> discussion? 3. What are the interactions about cached public keys,=20 >> when are these ok and how is this communicated to the client as a = failure? > > Sure. Some comments on your points for the discussion: > > 1. Ultimately the POP is about the owned private key used to sign by = the joining node. Building this part of the challenge this way ties the = challenge itself with the OSCORE context the two peers have. This is the = same construction we have in [1] for building a signature challenge, so = probably both documents would likely be affected. > > 2. Tokens covering multiple groups/topics are a next thing to define = in ace-key-groupcomm. Adapting this challenge-based POP will follow. As = a general case, the client wants to use different public keys in = different groups, which would mean providing one POP signature for each = key. Then, the N_S challenge can be as follows: > > --- If the Access Token is posted to /authz-info , the RS returns an = array of N_S, i.e. as many as the number X of groups/topics in the = 'scope' of the token. Since the client may then upload Y < X public keys = (some of which for more than one group), the client should include in = the joining request Y signatures, together with the respective used Y = N_C nonces and Y N_S nonces of the X provided by the Group Manager. > > --- If a TLS exporter is used, 'context_value' has to be non empty, = e.g. > it can include the public key or a hash of it. For simplicity, we may = want to have 'context_value' always non empty, i.e. also when only one = public key is involved and even in the simple case of one group/topic = only. > > --- In the OSCORE case, HMAC-Hash may take as 'salt' one more = concatenated element, e.g. the public key or a hash of it. For = simplicity, we may want to have 'salt' always including this additional = element, i.e. also when only one public key is involved and even in the = simple case of one group/topic only. > > 3. Cached public keys and how to handle them are discussed later in = Section 5. If something goes wrong, the joining process fails and the = Group Manager sends error responses as described in Section 4.3. > > > [1] > https://tools.ietf.org/html/draft-tiloca-ace-group-oscore-profile-01#s > ection-3.1 > > > >> Section 4.3 - Does it make sense to return a new rsnoce as part of=20 >> these errors? >> > > That's certainly possible, though I am not sure of the advantage, = compared to sticking to the first one returned in the response to the = Token POST. > > [JLS] depends on the "nonce" quality - that is one time only use. We can make it optional for the server to return a new nonce in the = error response. If received, the client has to use that latest nonce when building the = challenge to sign for the new joining request. Best, /Marco > Jim > > > -- > Marco Tiloca > Ph.D., Senior Researcher > > RISE Research Institutes of Sweden > Division ICT > Isafjordsgatan 22 / Kistag=C3=A5ngen 16 > SE-164 40 Kista (Sweden) > > Phone: +46 (0)70 60 46 501 > https://www.ri.se > > > -- Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se