[Hipsec] Digital Signature Algorithms

[[e-mail] (Julien Laganier)]

On Wednesday 13 October 2004 08:02, Pekka Nikander wrote:
> > So how does people feel about making both DSA and RSA mandatory
> > in HIP?
>
> I don't have any strong opinions.  IIRC, the usual IETF crypto
> guidelines state that
>
>    a) there must be at least one common MUST implement
>       algorithm that is considered secure enough
>
>    b) the algorithms must be negotiable so that if the
>       currently MUST implement turns out to be insecure,
>       the implementations can be easily upgraded to use
>       some other, new MUST implement algorithm
>
> Anyone care to check what the guidelines and other
> documents actually say?
>
>    draft-ietf-ipsec-ikev2-algorithms-05.txt

This one doesn't talk about RSA or DSS (only DH, PRF and HMAC). RSA=20
and DSS usage seems to be both MUST in draft-ietf-ipsec-ikev2-17.txt.=20

However, an interesting thing is the new requirements keywords defined=20
in draft-ietf-ipsec-ikev2-algorithms-05.txt:

SHOULD+            This term means the same as SHOULD. However it is
                   likely that an algorithm marked as SHOULD+ will be
                   promoted at some future time to be a MUST.
SHOULD-            This terms means the same as SHOULD. However an
                   algorithm marked as SHOULD- may be deprecated to a
                   MAY in a future version of this document.
MUST-              This term means the same as MUST. However we
                   expect at some point that this algorithm will no
                   longer be a MUST in a future document. Although
                   its status will be determined at a later time,it
                   is reasonable to expect that if a future revision
                   of a document alters the status of a MUST-
                   algorithm, it will remain at least a SHOULD or a
                   SHOULD-.

>=A0 =A0draft-iab-auth-mech-03.txt

It said:

=2D-------------------
While the desire to support legacy authentication systems is under-
standable, it should be resisted to the extent possible. Having mul-
tiple equivalent mechanisms dramatically increases both implementa-
tion complexity and interoperability problems. When designing a new
system, designers should choose a very small number of authentication
mechanisms, with no more than one of any given class.
=2D-------------------

And later

=2D-------------------
13.2. Use As Few Mechanisms as You Can

Preferably, systems should have only one form of authentication. The
more methods of authentication a system allows, the more things there
are to go wrong. Remember that a chain is only as strong as its weak-
est link. In general, there are two reasons why systems allow more
than one authentication mechanism. The first is that you're
retrofitting a system which already has a large number of authentica-
tion mechanisms which cannot be displaced. The second is that users
have widely different environments which for some reason cannot use
the same authentication mechanism conveniently (e.g. some users have
tokens and some do not).

Naturally, designers need to take such considerations into account
but they should take reasonable steps to minimize the number of mech-
anisms. Designers should take special care to minimize the number of
equivalent mechanisms. For instance, a system that provides a chal-
lenge/response mechanism and a public key based mechanism is a rea-
sonable design, one that provides three different challenge/response
mechanisms is not.

This doesn't mean that designers should not use security frameworks
where multiple mechanisms are appropriate, but it does mean that they
should be avoided unless necessary. Where generic security frameworks
are used, they supported mechanisms should be carefully profiled to a
minimal set.
=2D-------------------

>=A0 =A0crypto forum?

I can ask them.

>  From a robustness point of view, it would of course good to
> have multiple MUST implement algorithms.  OTOH, I think
> that there should also be some guidelines how to use them
> so that the chances of interoperability are maintained
> even in the case that one of the hosts only supports one
> algorithm, e.g., due to policy reasons.
>
> Maybe we could have DSA as MUST and RSA as SHOULD?
>
> --Pekka

I'm a bit confused by what I've read on the subject: IKEv2 has DSA as=20
MUST and RSA as MUST, but draft-iab-auth-mech says that it should be=20
avoided unless necessary.

If RSA is a SHOULD, HIP will probably needs a mean to negotiate HI=20
algorithm capabilities (between RSA and DSA), so I tend to think that=20
we should have both as MUST.

Is there any other opinions the subject?

Thanks,

=2D-julien