Re: iSCSI: SRP groups in Security-14 strawman

[Paul Koning <[e-mail]>]

> 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. 

You mentioned a short while ago that Tero Kivinen had undertaken to
prove the primality of the SRP primes, but I don't remember seeing a
followup report on that.  So until that is done, the IKE primes are
proven and the SRP primes are not yet proven. 

> 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.

If I remember right, there are performance benefits in some bignum
implementations to having a modulus with a bunch of leading and/or
trailing 1 bits.  The IKE primes are constructed to achieve that, the
SRP primes are not.  In other words, because of that construction
there IS value in allowing those primes; the IKE primes are NOT
superfluous and should be allowed whether or not there are primes in
the SRP reference software package of the same size.  In other words,
keep the 1024, 1536, and 2048 bit MODP primes, using the generator
that Tom Wu identified.

If you feel strongly that there should be only one prime modulus of
any given size, then I would argue that the preference should be the
IKE primes because of their construction.  

> 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.

I agree that only a single generator should be picked, so with the
proviso that we should also list the first acceptable generator for
the other IKE primes, your proposal sounds good.

> 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.

I like the approach of proposing a group identifier.  That's also
(roughly) what IKE does.
 
> (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.

I would tweak this slightly.

1. Given the high cost of bignum arithmetic in software, I'd prefer
   the mandatory lenghts to be smaller.  Orman's document says that
   a modulus size of 1553 matches a brute force strength of 90 bits.
   Given the amount of approximation in all that analysis, I'd say
   that we should set 1536 as the largest mandated size.

2. For the reason given earlier, mandate the MODP groups (rather
   than the SRP groups) up to the chosen mandatory size.  I'd propose
   1536, but if 2048 sticks then make it MODP-2048.  Reason: these are
   just as good as the SRP reference primes, and may be more efficient
   if your bignum implementation takes advantage of the clump of 1
   bits at start and end.

3. "... MUST offer" -- it doesn't have to be the first choice, right?
   I want to make sure that a customer who likes the cryptography
   underlying SRP but is worried about the performance of login
   (given a software implementation) is allowed to use, say, a 1024
   bit modulus by making that the first choice.

      paul