jiebi/CodeConvo huggingface dataset:
6. <del> Pre-shared Key (PSK) ciphersuites were first specified for TLS in 2005.  Now, PSK is an integral part of the TLS version 1.3 specification RFC8446.  TLS 1.3 also uses PSKs for session resumption.  It distinguishes these resumption PSKs from external PSKs which have been provisioned out-of-band (OOB).  Below, we list some example use-cases where pair-wise external PSKs (i.e., external PSKs that are shared between only one server and one client) have been used for authentication in TLS. </del> <ins> PSK ciphersuites were first specified for TLS in 2005.  Now, PSKs are an integral part of the TLS version 1.3 specification RFC8446.  TLS 1.3 also uses PSKs for session resumption.  It distinguishes these resumption PSKs from external PSKs which have been provisioned out- of-band (OOB).  Below, we list some example use-cases where pair-wise external PSKs (i.e., external PSKs that are shared between only one server and one client) have been used for authentication in TLS. </ins> Device-to-device communication with out-of-band synchronized keys. PSKs provisioned out-of-band for communicating with known
Keys (PSKs) in Transport Layer Security (TLS) 1.3 RFC8446.  This guidance also applies to Datagram TLS (DTLS) 1.3 I-D.ietf-tls-dtls13 and Compact TLS 1.3 I-D.ietf-tls-ctls.  For readability, this <del> document uses the term TLS to refer to all such versions.  External PSKs are symmetric secret keys provided to the TLS protocol </del> <ins> document uses the term TLS to refer to all such versions. External PSKs are symmetric secret keys provided to the TLS protocol </ins> implementation as external inputs.  External PSKs are provisioned <del> out-of-band.  This document lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks.  This document discusses PSK use cases, provisioning processes, and TLS stack implementation support in the context of these assumptions.  This document also provides advice for applications in various use cases to help meet these assumptions. </del> <ins> out-of-band. This document lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks.  This document discusses PSK use cases, provisioning processes, and TLS stack implementation support in the context of these assumptions.  This document also provides advice for applications in various use cases to help meet these assumptions. </ins> There are many resources that provide guidance for password generation and verification aimed towards improving security.
This document provides usage guidance for external Pre-Shared Keys (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446. <del> This document lists TLS security properties provided by PSKs under certain assumptions, and then demonstrates how violations of these assumptions lead to attacks.  This document discusses PSK use cases and provisioning processes.  This document provides advice for applications to help meet these assumptions.  This document also lists the privacy and security properties that are not provided by TLS 1.3 when external PSKs are used. </del> <ins> It lists TLS security properties provided by PSKs under certain assumptions, and then demonstrates how violations of these assumptions lead to attacks.  Advice for applications to help meet these assumptions is provided.  It also discusses PSK use cases and provisioning processes.  Finally, it lists the privacy and security properties that are not provided by TLS 1.3 when external PSKs are used. </ins> 1.
value and the receiving member's known identity.  See Selfie for details. <del> To illustrate the rerouting attack, consider the group of peers who know the PSK be "A", "B", and "C".  The attack proceeds as follows: </del> <ins> To illustrate the rerouting attack, consider three peers, "A", "B", and "C", who all know the PSK.  The attack proceeds as follows: </ins> "A" sends a "ClientHello" to "B".
Entropy properties of external PSKs may also affect TLS security properties.  For example, if a high entropy PSK is used, then PSK- only key establishment modes provide expected security properties for <del> TLS, including, for example, including establishing the same session keys between peers, secrecy of session keys, peer authentication, and downgrade protection.  See RFC8446, Section E.1 for an explanation of these properties.  However, these modes lack forward security. Forward security may be achieved by using a PSK-DH mode, or, alternatively, by using PSKs with short lifetimes. </del> <ins> TLS, including establishing the same session keys between peers, secrecy of session keys, peer authentication, and downgrade protection.  See RFC8446, Section E.1 for an explanation of these properties.  However, these modes lack forward security.  Forward security may be achieved by using a PSK-DH mode, or, alternatively, by using PSKs with short lifetimes. </ins> In contrast, if a low entropy PSK is used, then PSK-only key establishment modes are subject to passive exhaustive search attacks
This section lists some example use-cases where pair-wise external PSKs, i.e., external PSKs that are shared between only one server and <del> one client, have been used for authentication in TLS. </del> <ins> one client, have been used for authentication in TLS.  There was no attempt to prioritize the examples in any particular order. </ins> Device-to-device communication with out-of-band synchronized keys. PSKs provisioned out-of-band for communicating with known
different online protocol. Intra-data-center communication.  Machine-to-machine communication <del> within a single data center or PoP may use externally provisioned PSKs, primarily for the purposes of supporting TLS connections with early data; see security-con for considerations when using early data with external PSKs. </del> <ins> within a single data center or point-of-presence (PoP) may use externally provisioned PSKs, primarily for the purposes of supporting TLS connections with early data; see security-con for considerations when using early data with external PSKs. </ins> Certificateless server-to-server communication.  Machine-to- machine communication may use externally provisioned PSKs,
PSK into the devices, or using a Trust On First Use (TOFU) approach with a device completely unprotected before the first login did take place.  Many devices have very limited UI.  For <del> example, they may only have a numeric keypad or even less number of buttons.  When the TOFU approach is not suitable, entering the key would require typing it on a constrained UI. </del> <ins> example, they may only have a numeric keypad or even fewer buttons.  When the TOFU approach is not suitable, entering the key would require typing it on a constrained UI. </ins> Some devices provision PSKs via an out-of-band, cloud-based syncing protocol. <del> Some secrets may be baked into or hardware or software device </del> <ins> Some secrets may be baked into hardware or software device </ins> components.  Moreover, when this is done at manufacturing time, secrets may be printed on labels or included in a Bill of Materials for ease of scanning or import.
The method the client instance uses to send an access token depends on whether the token is bound to a key, and if so which proofing method is associated with the key.  This information is conveyed in <del> the "key" and "proof" parameters in response-token-single. </del> <ins> the "bound" and "key" parameters in response-token-single and response-token-multiple responses. </ins> <del> If the "key" value is the boolean "false", the access token is a bearer token sent using the HTTP Header method defined in RFC6750. </del> <ins> If the "bound" value is the boolean "true" and the "key" is absent, the access token MUST be sent using the same key and proofing mechanism that the client instance used in its initial request (or its most recent rotation). </ins> <del> The form parameter and query parameter methods of RFC6750 MUST NOT be used. </del> <ins> If the "bound" value is the boolean "true" and the "key" value is an object as described in key-format, the access token MUST be sent using the key and proofing mechanism defined by the value of the "proof" field within the key object. </ins> <del> If the "key" value is the boolean "true", the access token MUST be sent using the same key and proofing mechanism that the client instance used in its initial request (or its most recent rotation). </del> <ins> The access token MUST be sent using the HTTP "Authorization" request header field and the "GNAP" authorization scheme along with a key proof as described in binding-keys for the key bound to the access token.  For example, a "jwsd"-bound access token is sent as follows: </ins> <del> If the "key" value is an object as described in key-format, the value of the "proof" field within the key indicates the particular proofing mechanism to use.  The access token is sent using the HTTP authorization scheme "GNAP" along with a key proof as described in binding-keys for the key bound to the access token.  For example, a "jwsd"-bound access token is sent as follows: </del> <ins> If the "bound" value is the boolean "false", the access token is a bearer token that MUST be sent using the "Authorization Request Header Field" method defined in RFC6750. The "Form-Encoded Body Parameter" and "URI Query Parameter" methods of RFC6750 MUST NOT be used. </ins> [[ See issue #104 [47] ]] <ins> The client software MUST reject as an error a situation where the "bound" value is the boolean "false" and the "key" is present. </ins> 7.3. Any keys presented by the client instance to the AS or RS MUST be
REQUIRED.  A unique access token for continuing the request, in the format specified in response-token-single.  This access token MUST be bound to the client instance's key used in the request and <del> MUST NOT be a "bearer" token.  As a consequence, the "bound" field of this access token is always the boolean value "true" and the </del> <ins> MUST NOT be a "bearer" token.  As a consequence, the "flags" array of this access token MUST NOT contain the string "bearer" and the </ins> "key" field MUST be omitted.  This access token MUST NOT be usable at resources outside of the AS.  The client instance MUST present the access token in all requests to the continuation URI as
ASCII characters to facilitate transmission over HTTP headers within other protocols without requiring additional encoding. <del> RECOMMENDED.  Flag indicating if the token is bound to the client instance's key.  If the boolean value is "true" or the field is omitted, and the "key" field is omitted, the token is bound to the request-client in its request for access.  If the boolean value is "true" or the field is omitted, and the "key" field is present, the token is bound to the key and proofing mechanism indicated in the "key" field.  If the boolean value is "false", the token is a bearer token with no key bound to it and the "key" field MUST be omitted. </del> REQUIRED for multiple access tokens, OPTIONAL for single access token.  The value of the "label" the client instance provided in the associated request-token, if present.  If the token has been
MUST be able to dereference or process the key information in order to be able to sign the request. <ins> OPTIONAL.  A set of flags that represent attributes or behaviors of the access token issued by the AS. The values of the "flags" field defined by this specification are as follows: This flag indicates whether the token is bound to the client instance's key.  If the "bearer" flag is present, the access token is a bearer token, and the "key" field in this response MUST be omitted.  If the "bearer" flag is omitted and the "key" field in this response is omitted, the token is bound the request-client in its request for access.  If the "bearer" flag is omitted, and the "key" field is present, the token is bound to the key and proofing mechanism indicated in the "key" field. </ins> OPTIONAL.  Flag indicating a hint of AS behavior on token <del> rotation.  If this flag is set to the value "true", then the client instance can expect a previously-issued access token to continue to work after it has been rotate-access-token or the underlying grant request has been continue-modify, resulting in the issuance of new access tokens.  If this flag is set to the boolean value "false" or is omitted, the client instance can </del> <ins> rotation.  If this flag is present, then the client instance can expect a previously-issued access token to continue to work after it has been rotate-access-token or the underlying grant request has been continue-modify, resulting in the issuance of new access tokens.  If this flag is omitted, the client instance can </ins> anticipate a given access token will stop working after token rotation or grant request modification.  Note that a token flagged as "durable" can still expire or be revoked through any normal
Indicates that interaction through some set of defined mechanisms needs to take place. <del> Claims about the RO as known and declared by the AS. </del> <ins> Claims about the RO as known and declared by the AS, as described in response-subject. </ins> An identifier this client instance can use to identify itself when making future requests. <del> An identifier this client instance can use to identify its current end-user when making future requests. </del> An error code indicating that something has gone wrong. In this example, the AS is returning an response-interact-redirect, a
If information about the RO is requested and the AS grants the client instance access to that data, the AS returns the approved information <del> in the "subject" response field.  This field is an object with the following OPTIONAL properties. </del> <ins> in the "subject" response field.  The AS MUST return the "subject" field only in cases where the AS is sure that the RO and the end-user are the same party.  This can be accomplished through some forms of authorization. This field is an object with the following OPTIONAL properties. </ins> An array of subject identifiers for the RO, as defined by I- D.ietf-secevent-subject-identifiers.
information through an identity API.  The definition of such an identity API is out of scope for this specification. <del> The AS MUST return the "subject" field only in cases where the AS is sure that the RO and the end-user are the same party.  This can be accomplished through some forms of authorization. </del> Subject identifiers returned by the AS SHOULD uniquely identify the RO at the AS.  Some forms of subject identifier are opaque to the client instance (such as the subject of an issuer and subject pair),
All dynamically generated handles are returned as fields in the root JSON object of the response.  This specification defines the <del> following dynamic handle returns, additional handles can be defined in IANA. </del> <ins> following dynamic handle return, additional handles can be defined in IANA. </ins> A string value used to represent the information in the "client" object that the client instance can use in a future request, as described in request-instance. <del> A string value used to represent the current user.  The client instance can use in a future request, as described in request- user-reference. This non-normative example shows two handles along side an issued </del> <ins> This non-normative example shows one handle along side an issued </ins> access token. [[ See issue #77 [23] ]]
REQUIRED.  The URI at which the client instance can make continuation requests.  This URI MAY vary per request, or MAY be <del> stable at the AS if the AS includes an access token.  The client instance MUST use this value exactly as given when making a continue-request. </del> <ins> stable at the AS.  The client instance MUST use this value exactly as given when making a continue-request. </ins> RECOMMENDED.  The amount of time in integer seconds the client instance SHOULD wait after receiving this continuation handle and
Any keys presented by the client instance to the AS or RS MUST be validated as part of the request in which they are presented.  The <del> type of binding used is indicated by the proof parameter of the key object in key-format.  Values defined by this specification are as follows: </del> <ins> type of binding used is indicated by the "proof" parameter of the key object in key-format.  This parameter is formally specified by an object with at least the following member: Individual methods MAY define additional parameters as members in this object. Values for the "method" defined by this specification are as follows: </ins> Additional proofing methods are defined by IANA. <ins> For example, the "httpsig" method can be specified with its parameters as: If additional parameters are not required or used for a specific method, the method MAY be passed as a string instead of an object. For example, the "mtls" method with no additional parameters could be sent by the client instance as: The AS would map this to the equivalent expanded form as follows: </ins> All key binding methods used by this specification MUST cover all relevant portions of the request, including anything that would change the nature of the request, to allow for secure validation of
7.3.1. <del> This method is indicated by "httpsig" in the "proof" field.  The signer creates an HTTP Message Signature as described in I-D.ietf- httpbis-message-signatures. </del> <ins> This method is indicated by the method value "httpsig".  The signer creates an HTTP Message Signature as described in I-D.ietf-httpbis- message-signatures.  This method defines the following parameters: </ins> The covered components of the signature MUST include the following:
7.3.2. <del> This method is indicated by "mtls" in the "proof" field.  The signer presents its TLS client certificate during TLS negotiation with the verifier. </del> <ins> This method is indicated by the method value "mtls".  This method defines no additional parameters.  The signer presents its TLS client certificate during TLS negotiation with the verifier. </ins> In this example, the certificate is communicated to the application through the "Client-Cert" header from a TLS reverse proxy, leading to
7.3.3. <del> This method is indicated by "jwsd" in the "proof" field.  A JWS RFC7515 object is created as follows: </del> <ins> This method is indicated by the method value "jwsd".  This method defines no additional parameters.  A JWS RFC7515 object is created as follows: </ins> To protect the request, the JOSE header of the signature contains the following claims:
groupcomm, and it is RECOMMENDED to perform them according to the approach described in I-D.ietf-ace-key-groupcomm-oscore. <ins> 5.3. Different solutions may be selected for secure group communication via a proxy depending on proxy type, use case and deployment requirements.  In this section the options based on Group OSCORE are listed. For a client performing a group communication request via a forward- proxy, end-to-end security should be implemented.  The client then creates a group request protected with Group OSCORE and unicasts this to the proxy.  The proxy adapts the request from a forward-proxy request to a regular request and multicasts this adapted request to the indicated CoAP group.  During the adaptation, the security provided by Group OSCORE persists, in either case of using the group mode or using the pairwise mode.  The first leg of communication from client to proxy can optionally be further protected, e.g., by using (D)TLS and/or OSCORE. For a client performing a group communication request via a reverse- proxy, either end-to-end-security or hop-by-hop security can be implemented.  The case of end-to-end security is the same as for the forward-proxy case. The case of hop-by-hop security is only possible if the proxy can be completely trusted and it is configured as a member of the OSCORE security group(s) that it needs to access, on behalf of clients.  The first leg of communication between client and proxy is then protected with a security method for CoAP unicast, such as (D)TLS, OSCORE or a combination of such methods.  The second leg between proxy and servers is protected using Group OSCORE.  This can be useful in applications where for example the origin client does not implement Group OSCORE, or the group management operations are confined to a particular network domain and the client is outside this domain. For all the above cases, more details on using Group OSCORE are defined in I-D.tiloca-core-groupcomm-proxy. </ins> 6. This section provides security considerations for CoAP group
secure delegation.  The zone signing and secure delegation may be performed either by the Homenet Naming Authority or by the Outsourcing Infrastructure. sec-dnssec-deplyment discusses these two <del> alternatives. sec-views discusses the consequences of publishing multiple representations of the same zone also commonly designated as views.  This section provides guidance to limit the risks associated with multiple views.  sec-reverse discusses management of the reverse zone. sec-renumbering discusses how renumbering should be handled. </del> <ins> alternatives. sec-reverse discusses management of the reverse zone. sec-renumbering discusses how renumbering should be handled. </ins> Finally, sec-privacy and sec-security respectively discuss privacy and security considerations when outsourcing the Homenet Zone. <ins> The Homenet Zone is expected to host public information only.  It is not the scope of this DNS service to define local home network boundaries.  Instead, local scope information is expected to be provided to the home network using local scope naming services. mDNS RFC6762 DNS-SD RFC6763 are two examples of these services.  Currently mDNS is limited to a single link network.  However, future protocols are expected to leverage this constraint as pointed out in RFC7558. </ins> 3. Customer Premises Equipment: (CPE) is a router providing
As depicted in fig-naming-arch and fig-auth-servers, the Public Homenet Zone is hosted on the Public Authoritative Server(s), whereas <del> the Homenet Zone is hosted on the HNA.  Motivations for keeping these two zones identical are detailed in sec-views, and this section considers that the HNA builds the zone that will be effectively published on the Public Authoritative Server(s).  In other words "Homenet to Public Zone transformation" is the identity also commonly designated as "no operation" (NOP). </del> <ins> the Homenet Zone is hosted on the HNA.  This section considers that the HNA builds the zone that will be effectively published on the Public Authoritative Server(s).  In other words "Homenet to Public Zone transformation" is the identity also commonly designated as "no operation" (NOP). </ins> In that case, the Homenet Zone should configure its Name Server RRset (NS) and Start of Authority (SOA) with the values associated with the
otherwise a resolution with the Public Authoritative Server(s) would be performed. <del> 2) Keeping the Homenet Zone and the Public Homenet Zone equal to </del> <ins> Keeping the Homenet Zone and the Public Homenet Zone equal to </ins> securely address the connectivity disruption independence detailed in RFC7368 section 4.4.1 and 3.7.5.  As local lookups are possible in case of network disruption, communications within the home