Re: [IPsec] Shepherd review of the draft-ietf-ipsecme-add-ike

[Tero Kivinen <[e-mail]>]

Valery Smyslov writes:
> > In section 3.2 it is not clear what the length of the Hash Algorithm
> > Identifiers fields is. It contains list of hash algorithms or one hash
> > algorithm if this is response, but it is not clear what is response.
> 
> What was meant is that a list of hashes is sent by a client (in
> CFG_REQUEST) and a single hash is sent by a server (in CFG_REPLY).

Yes, and I think it is easier to understand if we have two figures,
one for the CFG_REQUEST and another for CFG_REPLY/CFG_SET. 

> > We have CFG_REQUEST, CFG_REPLY, CFG_SET, and CFG_ACK. Most likely
> > CFG_REPLY and CFG_ACK are sent in IKE exchange response. On the other
> > hand CFG_SET is usually used to set the parameters, thus the
> > Certificate Digest would be required there.
> 
> True, but IKEv2 doesn't currently use CFG_SET/CFG_ACK and
> it explicitly allows implementations to ignore them.

True, but you do include some text in some places about the CFG_ACK
for example, so for completeness it would be good to define them in
same way than RFC7296 does.

I.e., CFG_SET is same as CFG_REPLY, and CFG_ACK is always empty (i.e.,
length = 0, and no other fields after that).

> >                         1                   2                   3
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >    +-+-----------------------------+-------------------------------+
> >    |R|         Attribute Type      |            Length             |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> >      Figure 4: ENCDNS_DIGEST_INFO Attribute Format for CFG_ACK.
> > 
> > and then explain the Hash Algorithm Identifier and List of Hash
> > Algorithm Identifiers separately.
> 
> We may do this for completeness, but as I've already mentioned
> CFG_SET/CFG_ACK are not currently used in IKEv2. So I'm in not sure
> if this is really needed and won't further confuse implementers...

I think first two ones are needed, the last one can be left out and
simply say in length definition that it is zero for CFG_ACK, just like
you do for ENCDNS_IP*.

> > Actually is there any point of having ADN Length and Authenticated
> > Domain Name in CFG_REQUESTS ever? Why would someone calculate hashes
> > with certain domain names with different hash algorithms? Perhaps we
> > should define the format for CFG_REQUEST as follows:
> > 
> > 
> >                         1                   2                   3
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >    +-+-----------------------------+-------------------------------+
> >    |R|         Attribute Type      |            Length             |
> >    +-------------------------------+-------------------------------+
> >    ~              List of Hash Algorithm Identifiers               ~
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> >      Figure 3: ENCDNS_DIGEST_INFO Attribute Format for CFG_REQUEST
> 
> I'm confused, since CFG_REQUEST doesn't include Digest.
> Am I missing your point?

Thats the point. As the CFG_REQUEST does not include Certificate
Digest, it only includes list of hash algorithms, there is no point of
having Authentication Domain Name there either. So the ADN Length of
CFG_REQUEST will always be zero, and Authentication Domain Name is
omitted, but then we could simply omit the RESERVED and ADN Length
fields also for more optimal encoding. I.e., if as we already have
different format for CFG_REQUEST and CFG_REPLY/CFG_SET then making
them even more different does not matter.

If we want to keep the format same for all CFG_* then we need to
format this payload as follows:


                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-----------------------------+-------------------------------+
   |R|         Attribute Type      |            Length             |
   +-+-----------------------------+---------------+---------------+
   |            RESERVED           | Num Hash Algs |  ADN Length   |
   +-----------------------------------------------+---------------+
   ~                  Authentication Domain Name                   ~
   +---------------------------------------------------------------+
   ~                  Hash Algorithm Identifiers                   ~
   +---------------------------------------------------------------+
   ~                     Certificate Digest                        ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Where for CFG_REQUEST the Num Hash Algs tells how many hash algorithms
there are in the Hash Algorithm Identifiers list, and ADN Length will
be zero, and Authentication Domain Name and Certificate Digest are
omitted.

For CFG_REPLY/CFG_SET the Num Hash Algs MUST be one, and Hash
Algoritms Identifiers includes exactly one hash algorithm identifier
which is used to calculate the Certificate Digest.

With this payload format the decoder for this configuration payload
attribute does not need to know the type of the Configuration Payload
CFG Type, it can decode and encode the payload without knowing that
information, and the actual code that fills or uses them can then do
checking whether they have suitable fields set to suitable values.

But either one of those ways is fine, I would assume you as an
implementor has more preference which one is nicer than we others who
most likely will not do implementation of this.

> > I would prefer the SPKI (Subject Public Key Info) selector field way
> > of RFC7671, as then it does not matter if the certificate is renewed
> > etc.
> 
> Does certificate renewal matter in this case?

Not really, but for TLSA certificates I have been mostly using SPKI
and when I need to renew certificate because it expired, I will simply
reuse the private/public key and generate new certificate, and as I am
using SPKI I do not need to update my dns zone when I do that. I would
assume I am not alone in this situation, but I have no idea what will
be the operational practices for these certificates.

Both full certificate and SPKI digest allow checking that key is
correct, but full certificate digest might get broken in case there is
different certificates in the VPN gateway and the DNS server (i.e.,
DNS server hash renewed its certificate with same public key, but this
has not yet been migrated to the configuration of the VPN gateway). 

> > I do not think the [Hash] is normative reference. I did not need to
> > read and understand that to somewhat understand this document :-)
> 
> Well, it's only 58 words including title, you may read them in few
> seconds :-) Kidding aside, how this can be informative? The document
> uses these codepoints.

I usually have been considered things to normative if you need to read
and understand to be able to implement the protocol. In most of the
cases the information in IANA registries are already in the normative
reference RFCs, thus having normative reference to one iana registry 
is not needed. The reason I pointed this out is because the ID nits
complained about possible downref for having normative reference to
non-rfc document...
-- 
[e-mail]