RE: iSCSI: SRP groups in Security-14 strawman

[[e-mail]]

My main concern was that we don't allow more options than necessary; so picking either the SRP or the IKE moduli with their corresponding generators (one per modulus) seems OK to me. 

I do, however, share Paul Koning's desire to understand if there is an algorithmic advantage in using one modulus over another and hope, as does Paul, that somebody with the required background can be enlisted to shed some light on this. 

In hardware implementations of modular exponentiation I can conceive of potentially big impacts in the choice of base (generator) and modulus. Since the modular exponentiations for SRP and IKE are typically done in software and involve such large numbers I don't know if existing algorithms have taken advantage of optimizations that may be possible with certain choices of generator and modulus.

Vince

|-----Original Message-----
|From: [e-mail] [mailto:[e-mail]]
|Sent: Wednesday, July 24, 2002 4:12 PM
|To: [e-mail]; [e-mail]
|Subject: iSCSI: SRP groups in Security-14 strawman
|
|
|The SRP group specifications appear to need some tightening.  In
|reading this message, please keep in mind that SRP support is OPTIONAL,
|so the following concerns apply only to implementations that choose
|to support SRP.  To be specific, there is no requirement to offer or
|accept SRP as a value of AuthMethod.  Those with no plans to support
|SRP can ignore the rest of this message.
|
|Let me start with the following issue that Vince Cavanna raised:
|
|> Sounds good, but I don't understand the motivation to use any primes
|> other than those from IKE when we know those primes are certifiable
|> and that a generator suitable for SRP can be easily and 
|deterministically
|> determined. Is there value in giving the user multiple 
|choices for primes
|> of a given size?
|
|I think the answer to Vince's second question is "no", but I also
|think that since the SRP primes have been proven prime and have been
|widely distributed with SRP software from Stanford, we should
|choose them over the IKE primes.  The 2048 bit size of the largest
|SRP prime also appears to be convenient - see below.  This suggests
|deleting the Oakley group 2, the 1536-bit [MODP] group, and the
|2048-bit [MODP] group since there are SRP groups with primes of
|the same sizes.
|
|For the remaining MODP groups, I suggest that we pick a single
|acceptable generator for simplicity (i.e., that generator MUST
|be used with the corresponding prime, other generators MUST NOT
|be used):
|
|	5 for the 3072-bit, 4096-bit, and 6144-bit [MODP] groups.
|	19 for the 8192-bit [MODP] group.
|
|The rationale for this is the same as above - there is no value in
|giving the user multiple choices for generators.  Tom Wu should be
|cited as the source of the acceptability determination for these
|generators.
|
|Finally, we need some implementation requirements.  There are a
|couple of issues here:
|
|(1) For SRP, the target announces the prime and generator.  If the
|initiator doesn't like them, it closes the connection - that's an
|invitation to interoperability headaches.  The cleanest solution
|to this is to negotiate the group:
|	- Instead of the target sending SRP_N and SRP_g, the target
|		sends SRP_GROUP=<list-of-groups> where possible values
|		are SRP-768, SRP-1024, etc. and MODP-3072, 
|MODP-4096, etc.
|	- The initiator returns SRP_GROUP=<group it chose> along with
|		SRP_A.
|Not only is that cleaner, it also takes out a bignum without adding a
|round trip.  The SRP_GROUP values probably need to go into an IANA
|registry, with a rule that the WG (or the ADs if the WG no longer
|exists) control additions.  The alternative of folding the group
|selection into the AuthMethod value (e.g., AuthMethod=SRP_MODP-4096)
|seems clumsy by comparison and doesn't save a round trip.
|
|(2) We need some requirements on what MUST be supported for
|interoperability when SRP is supported.  I hesitate to require
|support for all the groups up to the 8192-bit MODP group.  A glance
|at draft-orman-public-key-lengths-05.txt suggests that the SRP
|primes are adequate for now as the 1536-bit and 2048-bit primes
|bracket the 96 bits of randomness that we require of CHAP secrets.
|
|In practice, I think we need to allow local security policy to
|disallow use of smaller primes, so the requirements would be
|something like:
|
|- MUST support all the SRP groups (up to 2048 bits)
|- MAY support the MODP groups
|- Target MUST offer SRP-2048 as one of the possible values of
|	SRP_GROUP and SHOULD offer all supported groups that are
|	allowed by local security policy.
|
|Comments?  Please keep in mind that all of the above would apply
|only to implementations that support SRP, and support for SRP is
|OPTIONAL.
|
|Thanks,
|--David
|---------------------------------------------------
|David L. Black, Senior Technologist
|EMC Corporation, 42 South St., Hopkinton, MA  01748
|[phone]            FAX: [phone]
|[e-mail]       Mobile: [phone]
|---------------------------------------------------
|