iSCSI: SRP groups in Security-14 strawman

[[e-mail]]

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