Hi Russ,
please see inline (I removed parts where we are in agreement).
> Valery:
>
> >> I find the use of GIKE_REKEY and GSA_REKEY a little bit confusing.
> >> I think it would help the reader if these were discussed a bit in the
Introduction.
> >
> > GSA_REKEY is an type of G-IKEv2 (pseudo) exchange, it appears in the G-
> IKEv2 Header (Exchange Type field).
> > The GIKE_REKEY is a protocol name, it appears in the GSA (and also in
SAg)
> payload.
>
> I think I figured it out, but I had to go back to do so. I suspect other
readers will
> need the hint too.
We discussed this with Brian and he suggested to change the name of the
protocol ID:
s/GIKE_REKEY/GIKE_UPDATE
to decrease the chances of possible confusion: the exchange name and the
protocol ID name would have no common text.
Do you think that could be helpful?
> >> Section 1.2: To my ears, KEK and KWK are the same thing. Please add
> >> more words sto make the distinction more clear.
> >
> > I think we can make the definition of KEK more accurate:
> >
> > OLD:
> > Key Encryption Key (KEK)
> > The symmetric cipher key used in a Rekey SA to protect
> > distribution of new keys.
> >
> > NEW:
> > Key Encryption Key (KEK)
> > The symmetric key (or a set of keys) used in a Rekey SA to protect
> > its messages.
> >
> > Is this better?
>
> Yes, thanks.
After some discussion between the authors, we decided to further clarify the
meaning of KEK:
Key Encryption Key (KEK)
The symmetric key (or a set of keys) used in a Rekey SA to protect
its messages. The set of keys may include keys for encryption and
authentication, as well as keys for key wrapping.
Are you OK with this definition?
> >> Section 2.4.1.1: I am surprised that the "ICV is computed using the
> >> current KEK keys". Two things surprise me. First, I think there is
> >> only one "current KEK" at a time. Second, I expected the current
> >> authentication key to be used for the ICV computation.
> >
> > I changed:
> >
> > s/current KEK keys/current KEK
> >
> > First, "KEK keys" is a tautology, then the updated definition of KEK
> > says now that it is a key or a set of keys (e.g. one for encryption,
> > one for authentication), thus I think it is OK to use KEK for ICV
computation.
>
> That helps. Does anything further need said for AEADs?
I'm not sure this is helpful at this point. Section 3.4 does say
that for AEAD algorithms the authentication key from KEK is not used
(in fact, it is assumed that its length is zero and thus it is not extracted
from KEK key material). But the purpose this section
is to describe how AUTH payload is calculated and the mention of
payload encryption and ICV calculation should be read as:
"after we calculate the content of AUTH payload we do out
usual steps for protecting the message" with no detail.
Does this reasoning make sense?
> >> Section 4.5.3.2: DSS public keys should be phased out, so I
> >> discourage the inclusion of DSS in this document.
> >
> > G-IKEv2 follows the same recommendations on using crypto algorithms as
> > IKEv2, and this document is not the right place to change these
> recommendations.
> > The current recommendations (RFC 8247) mark DSS as "SHOULD NOT".
> > Until it is marked "MUST NOT" its use is still allowed and we have to
> > define format for DSS signatures.
>
> Okay. Not ideal at this point in time, but I understand.
After some discussion between the authors, we think that the current text
contains too many details about the encoding of public keys.
The encoding should be standardized by other documents, we should
only reference them as much as possible. Thus, we think that the text
should be:
* If digital signatures are used for the GSA_REKEY message
authentication then the content of the AUTH_KEY attribute is a
public key used for digital signature authentication. The public
key MUST be represented as DER-encoded ASN.1 object
SubjectPublicKeyInfo, defined in Section 4.1.2.7 of Internet X.509
Public Key Infrastructure Certificate and CRL Profile [RFC5280].
The algorithm field inside the SubjectPublicKeyInfo object MUST
match the content of the Signature Algorithm Identifier attribute
in the Authentication Method transform. When the id-RSASSA-PSS
object identifier appears in the algorithm field of the
SubjectPublicKeyInfo object, then the parameters field MUST
include the RSASSA-PSS-params structure.
The last requirement is from RFC 7670 (Generic Raw Public-Key Support for
IKEv2).
We found it difficult to reference this RFC (this requirement is in the text
and not in a dedicated section), thus we repeat it here.
This text also removes any mention of DSS.
Are you OK with this text?
> >> Minor Concerns:
> >>
> >> Section 4.5.4: Can the wrapped key be 94 bits? It appears that the
> >> payload is a number of octets, but no padding mechanism is described.
> >> The text is unclear because it says: "These bits..."
> >
> > I see no problem if it is 94 bits (although it would be weird).
> > The payload is a whole number of octets, the padding mechanism doesn't
> matter.
> > Thus, the GCKS can fill the key bits beyond the needed length up to
> > the whole (any, but most naturally - nearest) number of octets with any
value
> (zeroes, ones, random).
> > GMs will consume exactly the needed number of bits, the rest (padding)
will be
> thrown away.
>
> Yes, I know that 94 bots would be weird. I would expect the padding
mechanism
> to be important for interoperability.
We don't think the padding mechanism is important for interoperability here.
Both the GCKS and the GMs know the number of bits to be taken from the
keying material.
The remaining bits will not be used in any case, they can be arbitrary.
See also RFC 7296, Section 2.17. The prf+ function obviously generates
the keying material KEYMAT that is a whole number of bytes in size.
The subsequent text defines how keys are taken from KEYMAT,
and there is no restriction that individual keys are byte-aligned in size.
If some bits are left in KEYMAT after all keys are taken, then
it doesn't matter what these bits are.
> >> Optional payloads (for example: "[CERTREQ]") really confuse IDnits.
> >> They appear to be references that are missing. I'm not sure there is
> >> anything to be done at this point, but you might be able to think of a
way to
> handle it.
> >
> > The presentation language for ISAKMP/IKEv1/IKEv2 exchanges is used
> > since 1997, and IDnits keeps complaining about missing references.
> >
> > I think that the proper way to handle this issue is to update IDnits
> > so, that it can take xml as a source (as this is currently the only
> > authoritative RFC source) and then it would be easy for IDnits to ignore
the
> content of figures.
>
> I know. That is why I do not offer a proposal for fixing the situation.
I did - fix IDnits :-)
Regards,
Valery.
> Russ
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
