Subject: iSCSI: SRP groups in Security-14 strawman

From: [email-masked]
Date: Wed, 24 Jul 2002 19:11:36 -0400

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
+1 (508) 249-6449            FAX: +1 (508) 497-8018
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: Paul Koning <[email-masked]>
Date: Thu, 25 Jul 2002 11:25:35 -0400

> 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

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.  

> cited as the source of the acceptability determination for these

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.

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