[Swan-dev] Fwd: RFC-7457 : Need Clarifications :)

[Paul Wouters]

Hi Sahana,


> 1.  'authby' in ipsec.conf 
> In the ipsec.conf file, is the authby value going to be changed?
>     authby=rsasig (currently for libreswan)
>   
> authby will take values like 'dsssig' , 'ecdsa' ( if these are implemented in libreswan in future)
> 
> or is the operator going to specify authby = digsig (digital signature = 14) - I hope not.

So the questions that need answering are:

1) Do we need the capability to configure "oldstyle RSA" versus "rfc7427 RSA" ?
2) Do we ever want to prevent "oldstyle RSA" from being used on a per-conn basis?

I think that would not be needed. Possibly we want a global option to
disable the old style RSA when we want to avoid using its hardcoded
SHA1, but I doubt we can disable this for the next 5-10 years, so plenty
of time to postpone this decision.

So I think we would indeed have different values in authby= and leftauth / rightauth

One question I do have, is if it makes sense to support a digital
signature that does not match the signature scheme used by the CA to
sign the EE cert. That is, if we have an RSA based cert, can (and/or would we)
want to be able to do a signature scheme that is different. For example,
if the EE cert is signed by the CA using RSA-SHA1, should we allow
authby using RSA-SHA2? What about the other way around?

If this mapping is one-to-one, then by just specifying the leftcert= /
rightcert= we could pin the signature method.

Do we want to support raw ECC keys outside a certificate? Raw keys are
useful to us when we just store pubkey into DNSSEC and do not need a
certificate container, but no one else in the world is left using raw
keys it seems (although there is an interest in the IoT world, eg see
RFC-7250)

> I ask this because , with RFC 7427 , authtype will always be 'Digital Signature =14' and as initiator libreswan will always send a Hash algorithm
> Notification. And this will be the default behaviour.

For would still want to fallback to "old style RSA" if needed, and
preferably, the enduser/admin would not need to know this. So I
would want authby=rsasig to be configured for both of these, and
based on the NOTIFY to change our behaviour.

> If it does not receive a Hash algorithm Notification , then we know that the receiver does not support RFC 7427 and we fall back to the older method
> and send authtype as rsasig=1.

Exactly :)

> Also can authby have multiple values?
> 
> I'd like to know this because , if libreswan supported both RSA and ECDSA (in future) , then will the operator always specify auth type as
>  'RSA|ECDSA' or  just 'RSA' or just  'ECDSA' ? 

Ahh now you hit a sore spot :)

In the old freeswan days, we did support authby=rsasig|secret to do
either. But it was done purely in sed/awk script parsing. When that
was replaced by the current libipsecconf, support for it was dropped.
Then, it was sort of added back in, but the parser for it is terrible
in that this works:

 	authby=rsasig|secret

but these do not:

 	authby=secret|rsasig
 	authby=rsasig |secret
 	authby=rsasig | secret

Also, for other items, we use "," as seperator and not "|".


However, internally, these all map the the lset_t c->policy, which has
a single policy bit for each, eg POLICY_RSASIG and POLICY_PSK.
(note the mismatch of "secret" vs "psk" on top of this)

To make things trickier, some of these new signature algorithms are
only valid for ikev2 and not ikev1, and per default we allow conns
to be either (something we are looking at removing due to its
complications and the fact that no one else implemented this
flexibility anyway, so there isn't much use beyond interop with
ourselves).

I think ideally, we would interpret "|" as "," and update the docs to
use that, then allow new keywords to be used there. This would need
to apply to the symmetric authby and the asymmetric leftauth= and
rightauth= options.

> {In the below link  i saw a possibility of sharedkey|rsasig for authby , so just wondered if it could ever be rsasig|ecdsa 
> https://libreswan.org/man/ipsec.conf.5.html }

(note that html file needs updating, better to run "man ipsec.conf" on
the latest libreswan version)

> 2. How do we decide what to send in Hash Algorithm Notification?
> 
> It should be  based on the 'authtype' configured by the operator in the ipsec.conf.
> so i'll look at c->policy and decide.

For the initiator, this is what you do. For the responder, things are
more tricky. We could be "switching connection". Image we have 10
different connections, some with RSA some with ECDSA. Both support
rodawarriors coming from a random IP addresses. When the initial
IKE_INIT request/response happen, we do not know for sure that we
are on the "right" connection. So once we receive IKE_AUTH, and get
the CERTREQ/CERT and IDi payloads, we might decided to switch
connection.

I don't know how best to solve this problem. One option is to send
hash algorithms based on what our implementation supports, instead
of based on our configuration of the conn we suspect is being addressed.
Another option is to detect the mismatch while processing IKE_INIT,
and doing a connection switch to something that would match the
received NOTIFY.

The code related to this is refine_host_connection()

> If it is RSA then send only SHA1 (because the rest is not supported currently by libreswan)

Note that an additional problem related to this is that our authby methods
don't specify the hash algorithm. Should we add authby=rsa-sha256 as an
auth type?

> If libreswan supports ECDSA in future , then SHA2-256 , SHA2-384 , SHA2-512 should be sent.
> 
> Let us assume for a moment that Libreswan supports both RSA and ECDSA (this is likely to happen in future).
> Should I already send SHA1 , SHA2-256 , SHA2-384 , SHA2-512 ? (Because I know for sure that libreswan supports all these 4)
> Or Should I check the authtype and send only SHA1 if it is RSA and SHA2-256 , SHA2-384 , SHA2-512 if it is ECDSA ?

So this is easier to determine for the initiator than for the responder.
See above.

> I would prefer the former method , since it give more flexibility.
> 
> If the responder says he supports only SHA1 , I can set up a connection with RSA keys.
> If the responder says he supports only SHA2-384 , I can set up a connection with ECDSA keys.

Currently, we have no order of preference in the authby= list. Should
we? I don't know. And also this situation is different. The initiator
sends a list of all algorithms it is WILLING to do. The responder can
pick the one it prefers and respond with only that one (but again, see
above for a problem with that)

> 3. Would libreswan plan to add support for RSA with SHA2-256 , SHA2-384 and SHA2-512 ?

I think that makes sense yes. Since we already support CERT's signing
with RSA-SHA2, so we have all the building blocks to support this. The
less SHA1 the better :)

> I know this is less likely  to happen as ECDSA with the above mentioned Hash algorithms is stronger anyway.
> But I continue to ask this because RFC has sha256WithRSAEncryption , sha384WithRSAEncryption and sha512WithRSAEncryption as Identifiers.
> 
> So should our code comply to it?

It would be nice to have.

> And if SHA2-256 is received from the Responder in the Hash algorithm Notification  both  sha256WithRSAEncryption and ecdsa-with-sha256 would be
> valid algorithm Identifiers to be sent in the in AUTH request .

That seems scary. Does the RFC really say that? That would be worth
raising as an isue at the IPsec WG if that is true.

> 4. How do we handle a case of more than 1  Hash algorithms being received by the responder?

The initiator has commited to be willing to use any of the listed ones.
So the responder gets to pick its favourite. This is similar to how IKE
and IPsec transforms are handled, although there the transforms are
ordered and the initiator is supposed to put its favourite first. I'm
not sure if RFC-7427 says anything about the order? But ultimately, it
is up to the responder to select one (aka "Cause if you didn't like it,
then you shouldn't have put a ring on it" :)

> Sorry for the long email.

Don't be. The more you ponder these issues before writing code, the less
code you need to write (or throw away)

> The more number of times I read the RFC , the more number of questions and doubts :)

Excellent! You're picking up the problems of a protocol engineer pretty quickly :)

Paul