HI Paul,
> >> There is text about IDi/IDr payloads being used in IKE_INTERMEDIATE and
> >> then talk about SHOULD be identical to the ones in IKE_AUTH. I would
> >> prefer a
> >> different notify for this (eg SAM_IDi/SAM_IDr) to avoid implementers
> >> confusing/erroring on confusing these with the real IDi/IDr payloads.
> >
> > Hm, I'm not sure this would help implementers. Currently they have some
> > code that prepares IDi/IDr and they can re-use it for IKE_INTERMEDIATE.
>
> We use a state machine based on the payload types. But also we read in
> structures are store them based on the type. Now I have to be careful
> that I don't change the state's IDi/IDr midway and run into security
> issues.
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),
but is this is a real problem for your implementation, then we can introduce
SAM_IDI and SAM_IDR notifications, which content would have been formatted
as IDi/IDr payloads body. So, the exchange would look like:
Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ,]
[N(SUPPORTED_AUTH_METHODS)()]
HDR, SK {..., [N(SAM_IDI), [N(SAM_IDR),]]} -->
<-- HDR, SK {..., [CERTREQ,]
[N(SUPPORTED_AUTH_METHODS)(...)] }
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2, TSi, TSr,
[N(SUPPORTED_AUTH_METHODS)(...)] } -->
<-- HDR, SK {IDr, [CERT,]
AUTH, SAr2, TSi, TSr }
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?
> >> 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.
> >> There are oddities with the CERTREQ payload. Some implementations using a
> >> list of hashes in 1 CERTREQ, others using 1 hash per CERTREQ. This makes
> >> using
> >> a numbered cert link number a bit tricky. (eg number 2 of the 3rd CERTREQ).
> >
> > The draft assumes that a single list of CAs from all CERTREQ payloads is
> > formed,
> > so, the link contains the position of the CA from this list.
> >
> >> I'd much rather select based on hash, not number.
> >
> > It is possible, but will consume 19 bytes more for each announcement.
> > I also don't like that the information is duplicated in this case -
> > both CERTREQ and SUPPORTED_AUTH_METHODS will contain the same hashes.
> > It's better get rid of CERTREQ in this case, but this will break
> > interoperability
> > with unsupported implementations.
>
> I think in general when you have a CERTREQ payload and hashes of CAs,
> then you can derive the authentication method from it, as it will be
> the same as the CA used to sign the EE cert. That authentication method
> should be used to sigh the AUTH payload as well. And in most (sane)
> cases there is only 1 hash. I have seen CERTREQs with CA hashes of the
> entire webpki but I consider those to be a fatal error deployment.
>
> So I don't think the cost isn't that big.
>
> >> Additionally, implementations might build the CERTREQ payload and then
> >> throw it away. I wouldn't want to need to keep those around for this
> >> extension.
> >
> > My understanding, that when you receive a message, you start parsing it.
> > Until you fully parse it, you unlikely throw it away. The protocol currently
> > is constructed in such a way, that SUPPORTED_AUTH_METHOFS and CERTREQ are
> > in the same
> message,
> > except for one case - when the responder sends this information in
> > IKE_INTERMEDIATE.
> > It is possible to modify the protocol to duplicate CERTREQ in this message.
> > Would it eliminate your concern?
>
> I think I still prefer using the hash. For those who 19 bytes is a
> problem, they can configure their systems to only have one CA and they
> can omit the CERTREQ payload entirely. But also then they wouldn't need
> SUPPORTED_AUTH_METHODS either?
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?
Regards,
Valery.
> Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
