Generic Security Service Application Program Interface (GSS-API) Key Exchange with SHA-2
draft-ietf-curdle-gss-keyex-sha2-10

[Ballot comment]
Thank you for for writing this - it was clear enough that I could understand the bits that I needed to :-)

I have a few comments:
"Additionally we utilize also the curves defined in [I-D.ietf-curdle-ssh-curves] to complement the 3 classic NIST defined curves required by [RFC5656]."
I checked on the status of I-D.ietf-curdle-ssh-curves - this seems to have stalled. I realize it isn't your problem, but is there a plan to progress I-D.ietf-curdle-ssh-curves ?

"The parties generate each an ephemeral key pair, according to ..."
I think that this would be easier to understand as: "The parties each generate an ephemeral key pair, according to ..."

[Ballot comment]
Thanks to everyone who invested work in this document.

I support Alissa's discuss, especially in light of RFC 2743 being an IETF-stream
document.

---------------------------------------------------------------------------

§1:

>  SSH GSS-API Methods [RFC4462] allows the use of GSSAPI for
>  authentication and key exchange in SSH.

It seems that RFC 2743 needs to be included as a normative reference for
GSSAPI here.

---------------------------------------------------------------------------

§4:

>  Base64 encoding is described in
>  Section 6.8 of [RFC2045].

For uses outside of MIME, RFC 4648 is far more conventional to cite. You want to
point to section 4.

---------------------------------------------------------------------------

§5:

>  Additionally we utilize also the curves defined in
>  [I-D.ietf-curdle-ssh-curves] to complement the 3 classic NIST defined

Nit: "NIST-defined"

---------------------------------------------------------------------------

§5.1:

>  Key-agreement schemes ECDHE-Curve25519 and ECDHE-Curve448 perform the
>  Diffie-Helman protocol using the functions X25519 and X448,
>  respectively.  Implementations SHOULD compute these functions using
>  the algorithms described in [RFC7748].

I don't usually quibble of "SHOULD" versus "MUST," but it seems that any
implementation that doesn't heed this "SHOULD" simply won't interoperate. Unless
I'm completely misunderstanding how Diffie-Helman works, it seems that
this needs to be a "MUST" (or, in extremis, "MUST compute these functions using
the algorithms described in [RFC7748] or functionally equivalent algorithms.")

---------------------------------------------------------------------------

§5.1:

>  For NIST Curves the keys use the uncompressed point representation
>  and must be converted using the algorithm in Section 2.3.4 of
>  [SEC1v2].

"must" or "MUST"?

---------------------------------------------------------------------------

§5.1:

>  To verify the integrity of the handshake, peers use the Hash Function
>  defined by the selected Key Exchange method to calculate H:
>
>  H = hash(V_C || V_S || I_C || I_S || K_S || Q_C || Q_S || K).

Please indicate that these variables and the "||" operator will be described
later in this section.

---------------------------------------------------------------------------

§5.1:

>  The server may responds with:

Nit: "...may respond with:"

---------------------------------------------------------------------------

[Ballot discuss]
"The IESG is considered to be the owner of all these key exchange
  methods; this does NOT imply that the IESG is considered to be the
  owner of the underlying GSS-API mechanism."

I don't understand this text. What does it mean for the IESG to be the owner of a method?

[Ballot comment]
** Section 5.1, Per “The exchange hash SHOULD be kept secret”, when should it not be (i.e., why isn’t this a MUST?)?

Editorial Items:
** Section 2.  Provide a reference to X25519 and X448 Curves

** Section 3.  Typo.  s/>RFC2119/RFC2119/

** Section 4.  Editorial.  The sentence “The following new key exchange …” is indented.

** Section 4 and 5.2.  Per “Each key exchange method id implicitly registered by this document”, aren’t these key exchange methods explicitly registering them in IANA-KEX-NAMES per Section 7?

** Section 4.  Explicitly name, number and reference the table in the text

** Section 4.  Typo.  s/refences/references/

** Section 5.  Editorial. s/Additionally we utilize also/Additionally, we also utilize/

** Section 5.  Editorial.  s/3 classic/three classic/

** Section 5.1.  It is worth repeating (or moving the text) to Section 8 that the Security Considerations of RFC7546 apply

** Section 5.1.  Typo.  s/trasmitted/transmitted/

** Section 5.1. Typo.  s/estalishment/establishment/

** Section 5.1.  The various variable (e.g., V_C, V_S) are introduced early in the algorithm to construct H and the messages in page 6, but they aren’t described until the end of page 7.  I wasn’t following the narrative until I hit that section.

** Section 5.2.  Explicitly number the table and reference it in the text.

** Section 5.2.  Typo.  s/refences/references/

** Section 6.  This section references a table.  Explicitly name and number that table.

[Ballot comment]
-- Section 2 --

  we propose the use of the SHA-2 [RFC6234] based hashes

Two nits here: first, the second "the" seems odd.  Second, "SHA-2-based hashes" needs to be hyphenated, which makes the double hyphen odd and moves the citation.  I suggest, "we propose the use of hashes based on SHA-2 [RFC6234]".

-- Section 4 (and also 5.2) --

  Each key exchange method is implicitly registered by this document.

The registration is not implicit; it's explicit in Section 7.  I suggest removing "implicitly".

-- Section 8.3 --
Nits: "Some mechanisms implementations" should be "Some mechanism implementations", "(like commonly used krb5 libraries)" should be "(such as commonly used krb5 libraries)", and "may results" should be "may result".

[Ballot comment]
I'm sending this out for IESG evaluation, but there are still a couple nits that
can be fixed in the next revision:

There's a formatting oddity in the BCP 14 boilerplate in Section 3.

In Section 5, we seem to refer to Section 4 of [RFC5656] for GSS
context establishment, which is probably not the right reference,
since that document does not mention the GSS-API at all.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-curdle-gss-keyex-sha2-07. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Key Exchange Method Names registry on the Secure Shell (SSH) Protocol Parameters registry page located at:

https://www.iana.org/assignments/ssh-parameters/

ten new method names will be registered as follows:

Method Name: gss-group14-sha256-*
Reference: [ RFC-to-be ]
Note:

Method Name: gss-group15-sha512-*
Reference: [ RFC-to-be ]
Note:

Method Name: gss-group16-sha512-*
Reference: [ RFC-to-be ]
Note:

Method Name: gss-group17-sha512-*
Reference: [ RFC-to-be ]
Note:

Method Name: gss-group18-sha512-*
Reference: [ RFC-to-be ]
Note:

Method Name: gss-nistp256-sha256-*
Reference: [ RFC-to-be ]
Note:

Method Name: gss-nistp384-sha384-*
Reference: [ RFC-to-be ]
Note:

Method Name: gss-nistp521-sha512-*
Reference: [ RFC-to-be ]
Note:

Method Name: gss-curve25519-sha256-*
Reference: [ RFC-to-be ]
Note:

Method Name: gss-curve448-sha512-*
Reference: [ RFC-to-be ]
Note:

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-01-08):

From: The IESG
To: IETF-Announce
CC: draft-ietf-curdle-gss-keyex-sha2@ietf.org, ekr@rtfm.com, Daniel Migault , curdle-chairs@ietf.org, curdle@ietf.org, daniel.migault@ericsson.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (GSS-API Key Exchange with SHA2) to Proposed Standard


The IESG has received a request from the CURves, Deprecating and a Little
more Encryption WG (curdle) to consider the following document: - 'GSS-API
Key Exchange with SHA2'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-01-08. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document specifies additions and amendments to RFC4462.  It
  defines a new key exchange method that uses SHA-2 for integrity and
  deprecates weak DH groups.  The purpose of this specification is to
  modernize the cryptographic primitives used by GSS Key Exchanges.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7546: Structure of the Generic Security Service (GSS) Negotiation Loop (Informational - IETF stream)

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4544

This document has a huge amount of duplicated material which makes it
very hard to read. Please refactor so that the common material is in
one place.




COMMENTS
>      Due to security concerns with SHA-1 [RFC6194] and with MODP groups
>      with less than 2048 bits [NIST-SP-800-131Ar1]  we propose the use of
>      the SHA-2 based hashes with DH group14, group15, group16, group17 and
>      group18 [RFC3526].  Additionally we add support for key exchange
>      based on Elliptic Curve Diffie Hellman with NIST P-256, P-384 and
>      P-521 as well as X25519 and X448 curves.  Following the rationale of

"the X25519..."


>          +--------------------------+--------------------------------+
>          | Key Exchange Method Name | Implementation Recommendations |
>          +--------------------------+--------------------------------+
>          | gss-group14-sha256-*    | SHOULD/RECOMMENDED            |
>          | gss-group15-sha512-*    | MAY/OPTIONAL                  |
>          | gss-group16-sha512-*    | SHOULD/RECOMMENDED            |

Why are you only specifying SHA-512 with 4096-bit groups. SHA-256 is
still reasonable at that size?


> 
>      Each of these methods specifies GSS-API-authenticated Diffie-Hellman
>      key exchange as described in Section 2.1 of [RFC4462]  with SHA-256
>      as HASH, and the group defined in Section 8.2 of [RFC4253] The method
>      name for each method is the concatenation of the string "gss-
>      group14-sha256-" with the Base64 encoding of the MD5 hash [RFC1321]

Why is this MD5? Is there some legacy reason for this? It's not
necessarily bad but it's odd to modern eyes.


>      Each of these methods specifies GSS-API-authenticated Diffie-Hellman
>      key exchange as described in Section 2.1 of [RFC4462]  with SHA-512
>      as HASH, and the group defined in Section 7 of [RFC3526] The method
>      name for each method is the concatenation of the string "gss-
>      group18-sha512-" with the Base64 encoding of the MD5 hash of the
>      ASN.1 DER encoding of the underlying GSS-API mechanism's OID.

These all seem to be boilerplate. is there a way to refactor into a
single paragraph with a table that describes the substitutions?


>      ASN.1 DER encoding of the underlying GSS-API mechanism's OID.
> 
>  5.  New Elliptic Curve Diffie-Hellman Key Exchange methods
> 
>      In [RFC5656] new SSH key exchange algorithms based on Elliptic Curve
>      Cryptography are introduced.  We reuse much of section 4 to implement

s/implement/define/


>      This section defers to [RFC7546] as the source of information on GSS-
>      API context establishment operations, Section 3 being the most
>      relevant.  All Security Considerations described in [RFC7546] apply
>      here too.
> 
>      The Client:

This section should be refactored to put all the EC mechanics (which
are symmetrical) in one place.


>            and then y coordinate.  The coordinate coversion MUST preserve
>            leading zero octets.  Thus for nistp521 curve the encoded x
>            coordinate will always have a length of 66 octets while the Q_C
>            representation will be 133 octets long.  This is the
>            uncompressed representation specified in Section 4.3.6 of
>            [ANSI-X9-62-2005].

I have two questions about this:  1. Why are you specifying the
detailed computation of the public key? This seems like you could
defer it to another spec. 2. Why are you specifying uncompressed
representations for NIST curves? We did this in TLS because people
already supported them, but in general they are worse. Is there a
reason here?


>            by 31 zero octets for curve255519 and as an octect of value
>            0x05 followed by 55 zero octets.
> 
>            Calculating Q_C as the result of the call to X25519 or X448
>            function, respectively for curve25519 and curve448 key
>            exchange, with parameters d_C and g.

This material all seems to be in RFC 7748 S 6.1 and 6.2.


> 
>        For NIST curves, the server verifies that the q_C is not a point
>        at infinity, that both coordinates are in the interval [0, p - 1],
>        where p is the prime associated with the curve of the selected key
>        exchange and that the point lies on the curve (satisfies the curve
>        equation).

You should probably cite to the X9.62 or SP-800 for this procedure.


>        For curve25519, the server verifies that the the high-order bit of
>        the last octet is not set - this prevents distinguishing attacks
>        between implementations that use Montgomery ladder implementation
>        of the curve and ones that use generic elliptic-curve libraries.
>        If the bit is set, the key exchange SHOULD fail.  For curve448 any
>        bit can be set.

I'm not following what this is supposed to do. If you are worried
about this, why don't you just mask off the top bit.


>            For NIST curves, the peers perform point multiplication using
>            d_U and q_V to get point P.
> 
>            For NIST curves, peers verify that P is not a point at
>            infinity.  If P is a point at infinity, the key exchange MUST
>            fail.

Why is this text here? It describes the client's behavior.


>            and q_V.  The result of the function is the shared secret.
> 
>            For curve25519 and curve448, if all the octets of the shared
>            secret are zero octets, the key exchange MUST fail.
> 
>        H = hash(V_C || V_S || I_C || I_S || K_S || Q_C || Q_S || K).

This kind of just comes out of nowhere. You probably want some
prefatory text.


> 
>      7.  C verifies that the key Q_S is valid the same way it is done in
>      step 3.  If the key is not valid the key exchange MUST fail.
> 
>      8.  C computes the shared secret K and H and verifies that it is
>      valid the same way it is done in step 5.  It then calls

This check only applies to CFRG curves.


>          string    server public host key and certificates (K_S)
> 
>      Since this key exchange method does not require the host key to be
>      used for any encryption operations, this message is OPTIONAL.  If the
>      "null" host key algorithm described in Section 5 of [RFC4462] is
>      used, this message MUST NOT be sent.

I am assuming in this situation there is some other form of
authentication?


>          string    I_C, payload of the client's SSH_MSG_KEXINIT
>          string    I_S, payload of the server's SSH_MSG_KEXINIT
>          string    K_S, server's public host key
>          string    Q_C, client's ephemeral public key octet string
>          string    Q_S, server's ephemeral public key octet string
>          mpint    K,  shared secret

The actual equation is way up above this in the document, which is
presumably not great.


>      Each key exchange method is implicitly registered by this document.
>      The IESG is considered to be the owner of all these key exchange
>      methods; this does NOT imply that the IESG is considered to be the
>      owner of the underlying GSS-API mechanism.
> 
>  5.2.1.  gss-nistp256-sha256-*

Again, can you refactor this section so it's not so duplicative.


>      the target the user intended.  Some mechanisms implementations (like
>      commonly used krb5 libraries) may use insecure DNS resolution to
>      canonicalize the target name; in these cases spoofing a DNS response
>      that points to an attacker-controlled machine may results in the user
>      silently delegating credentials to the attacker, who can then
>      impersonate the user at will.

Is this something new in this document?

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The document requests the "standard track" type.  This is the
appropriated type as the document defines new key exchange
methods, deprecates weaker ones and provides recommendations.
These recommendations are necessary for interoperability
between the implementations. In addition, the draft updates
RFC4462 which is of standard track. 

The type is indicated din the header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

  This document specifies additions and amendments to SSH GSS-API
  Methods [RFC4462].  It defines a new key exchange method that uses
  SHA-2 for integrity and deprecates weak DH groups.  The purpose of
  this specification is to modernize the cryptographic primitives used
  by GSS Key Exchanges.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

The document has not raised any issue but received few
feed backs as well.


Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

The only currently know implementation are patches for OpenSSH in Fedora:
https://src.fedoraproject.org/rpms/openssh/blob/master/f/openssh-7.5p1-
gssapi-kex-with-ec.patch




Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Daniel Migault is the document shepherd Eric Rescorla is the
Security Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document seems ready to me.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No issues have been raised, although little reviews have been provided.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Both co-authors confirm they have no  disclosure and are conform with BCP 78 and BCP 79.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

Does not apply here.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

No issues have been raised.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

idnits 2.15.01

/tmp/draft-ietf-curdle-gss-keyex-sha2-05.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  -- The draft header indicates that this document updates RFC4462, but the
    abstract doesn't seem to directly say this.  It does mention RFC4462
    though, so this could be OK.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == Line 415 has weird spacing: '... string    out...'

  == Line 421 has weird spacing: '... string    ser...'

  == Line 433 has weird spacing: '... string    out...'

  == Line 446 has weird spacing: '... string    out...'

  == Line 460 has weird spacing: '... string    mic...'

  == (2 more instances...)

    (Using the creation date from RFC4462, updated by this document, for
    RFC5378 checks: 2005-08-23)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
    have content which was first submitted before 10 November 2008.  If you
    have contacted all the original authors and they are all willing to grant
    the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
    this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
    (See the Legal Provisions document at
    https://trustee.ietf.org/license-info for more information.)


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  -- Possible downref: Non-RFC (?) normative reference: ref. 'ANSI-X9-62-2005'

  ** Downref: Normative reference to an Informational RFC: RFC 1321

  ** Downref: Normative reference to an Informational RFC: RFC 7546

  ** Downref: Normative reference to an Informational RFC: RFC 7748

  -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC2v2'


    Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--).

    Run idnits with the --verbose option for more detailed information about
    the items above.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as
either normative or informative?

All references are either normative or informative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

I-D.ietf-curdle-ssh-curves is required and has been sent to the IESG.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

The downward normative references are:

ANSI-X9-62-2005 is added as a justification for the described representation of x. This is not an RFC but fall into the RFC 3967 category of standards defined by other standard bodies.

'ISO-IEC-8825-1' is necessary for the format of the code point as a result, it is expected to be a normative reference. This is not an RFC but fall into the RFC 3967 category of standards defined by other standard bodies.

RFC 1321, Rivest, R., "The MD5 Message-Digest Algorithm",  describes MD5 defined by an external body.

RFC 7546 Kaduk, B., "Structure of the Generic Security Service (GSS) Negotiation Loop" should be normative as security considerations apply here, and as such must be read by those implementing the specification.

RFC 7748, Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security" defines curves25519 and curve448. These specification are necessary for the implementation of the document. The specifications fall into the RFC3967 category of protocols defined by other bodies. 

'SEC2v2' Certicom Research, "SEC 2: Recommended Elliptic Curve Domain Parameters". The specifications fall into the RFC3967 category of protocols defined by other bodies. 


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

The current draft updates RFC 4462. This is stated in the Header, in the abstract and in the introduction.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

IANA assignment requires IETF review. There is no need to provide experts.
The registry has been specified to ease the reading.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

Does not apply here