On Fri, Apr 14, 2023 at 10:00 AM Valery Smyslov <smyslov.i...@gmail.com>
wrote:
>
> OK, I see your point. We use similar approach, but payload processing
> is also dependent on the exchange it is encountered (in addition to its
> type),
> so there is no problem to have same payloads in different exchanges for
> our implementation.
>
> I'm a bit reluctant to add new notifies for this purpose (following the
> Occam's Razor principle),
>
> [...]
> Alternatively, we may stick with IDi/IDr, but require that they MUST be
> identical to those in IKE_AUTH.
> Which approach is better for you?
>
With the MUST, I am okay with the approach. We can add the check and it
doesn't propose any new risks then.
Thanks!
> > >> There are two methods described, one for old style RSA/ECDSA and one
> for
> > >> Digital Signatures (RFC 7247, auth method 14). I would prefer to not
> support
> > >> the old style, as we are trying to obsolete those. These use
> undesirable
> > >> features anyway (RSA v1.5, sha-1, etc)
> > >
> > > That's a fair point. But what if some new authentication method
> appears in the future,
> > > that will unambiguously identify the authentication algorithm (so no
> additional information
> > > like AlgorithmIdentifier is needed? I prefer to keep the format
> (anyway, it is mostly the same,
> > > only length matters), but state, that currently this format (Len = 3)
> is not used.
> >
> > That's fine with me.
>
> Hmm, I checked RFC 8247 and it appears that "RSA Digital Signature" (1) is
> the only
> digital signature authentication method that is currently a MUST.
>
> Obviously, we cannot say "don't use MTI method with this extension" :-)
> So, I'd rather leave the text as is for now.
>
That's fair, although I think we will skip implementing it for (1)
There is one more reason for not using hashes. The format of the CERTREQ
> payload
> (list of 20-byte hashes) is only defined for Cert Encoding types 4, 12,
> and 13 (Section 3.7 of RFC 7296).
> It is possible that other formats are defined in the future (as explicitly
> stated in RFC 7296).
> Having this in mind, if we use value from CERTREQ payload for referencing
> CA, then it might potentially
> be much larger than 19 bytes. In addition, since the size may vary, a more
> complex format for
> Announcement is needed. For these reasons I still prefer to use
> referencing by ordinal number.
>
> Note, that referencing particular CA is optional, you may leave Cert Link
> field zeroed,
> meaning this announcement is not tied to any particular CA.
>
> To simplify linking announcements with CAs, I propose that CERTREQ
> payloads always accompany
> SUPPORTED_AUTH_METHODS, so that they always are in same message. To
> achieve this
> we only have to add CERTREQ to the IKE_INTERMEDIATE response:
>
> HDR, SK {..., [N(SAM_IDI), [N(SAM_IDR),]]} -->
> <-- HDR, SK {..., [CERTREQ,]
> [N(SUPPORTED_AUTH_METHODS)(...)] }
>
> because in all other cases this is already fulfilled. Opinions?
>
That works for me! Again, thanks!
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
