[Hipsec] Digital Signature Algorithms

[[e-mail] (Jari Arkko)]

I'd be fine with just one algorithm (for now).
And my slight preference for that algorithm is
RSA...

--Jari

Julien Laganier wrote:
> 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 
> and DSS usage seems to be both MUST in draft-ietf-ipsec-ikev2-17.txt. 
> 
> However, an interesting thing is the new requirements keywords defined 
> 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-.
> 
> 
>>   draft-iab-auth-mech-03.txt
> 
> 
> It said:
> 
> --------------------
> 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.
> --------------------
> 
> And later
> 
> --------------------
> 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.
> --------------------
> 
> 
>>   crypto 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 
> MUST and RSA as MUST, but draft-iab-auth-mech says that it should be 
> avoided unless necessary.
> 
> If RSA is a SHOULD, HIP will probably needs a mean to negotiate HI 
> algorithm capabilities (between RSA and DSA), so I tend to think that 
> we should have both as MUST.
> 
> Is there any other opinions the subject?
> 
> Thanks,
> 
> --julien
> _______________________________________________
> Hipsec mailing list
> [e-mail]
> http://honor.trusecure.com/mailman/listinfo/hipsec
> 
>