Re: iSCSI login authentication

[Paul Koning <ni1d@arrl.net>]

>>>>> "Williams" == Williams, Jim <Jim.Williams@emulex.com> writes:

 Williams> ...How long is it acceptable to take in performing or
 Williams> verifying authentication?  How big are the numbers
 Williams> involved?  There are public domain authentication software.
 Williams> Have experiments been done to determine the computation
 Williams> requirements on a typical embedded processor versus number
 Williams> size?

A note in 1999 on the ipsec lists quotes measurements by Eric Young:

    Some just generated numbers :-).

    mul  256 ^  256 % 256 ->     1.446ms
    mul  512 ^  512 % 512 ->     8.430ms
    mul 1024 ^ 1024 % 1024 ->   53.510ms
    mul 2048 ^ 2048 % 2048 ->  366.214ms
    mul 4096 ^ 4096 % 4096 -> 2519.000ms

    Pentium II 450, Visual C 6.0 + 586 
    asm.  This build is targeted at
    512^512%512

    eric
    --
    Eric Young | eay@pobox.com

 Williams> draft-ietf-ips-iscsi-12 states:

 Williams> "N [for SRP] is required to be a Sophie-German prime.
 Williams> [...] N MUST be at least 768 bits. [...]  The Initiator
 Williams> MUST verify that they satisfy the above requirements. [...]
 Williams> This verification MAY start by trying to match N and g with
 Williams> a well-known group that satisfies the above requirements."

 Williams> What is the maximum length of N?  Also stated is:

 Williams> "The length of N,g,s,A,B,M in binary form (not the length
 Williams> of the character string that represents them in encoded
 Williams> form) MUST not exceed 1024 bytes."

 Williams> 1024 bytes is 8192 bits.  Do we really want to allow
 Williams> numbers that big? 

The reason given for the 8192 bit length is to allow for future
growth.  That sounds reasonable.  

There's an I-D proposing D-H groups up to 8192 bits
(draft-ietf-ipsec-ike-modp-groups).  It looks like groups beyond 2048
are only interesting if you believe AES needs keys longer than 128
bits for your purposes.

 Williams> Also, why is selecting N and g from a well-known group a
 Williams> "MAY"?  Verifying that N is a Sophie-German prime by means
 Williams> of probabilistic primality testing requires significantly
 Williams> more computation than the authentication itself.  Also
 Williams> letting a target or initiator choses its own custimized
 Williams> value of N does not seem conducive to good security.

The standardized groups (at least for IKE) have had the primality of N
verified rigorously, not just probabilistically.  A probabilistic test
may be adequate for individual exchanges, but it feels a bit
uncomfortable. 

 Williams> I would suggest more appropriate might be something like:
 Williams> "N MUST be at least 768 bits.  N SHOULD be no larger than
 Williams> <TBD> bits and MUST be selected from the well-known group
 Williams> <xyz>.  If a target or initiator receives a proposed value
 Williams> of N larger than <TBD> bits it MAY be rejected.  and if it
 Williams> is not contained in the well-known group <xyz>, this value
 Williams> SHOULD (MUST??)  be rejected.  Otherwise the value of N
 Williams> SHOULD be accepted."

I proposed earlier that the ability to specify N and g should be
deleted and replaced by an enumerated list of specific standarized
groups, exactly as IKE does it.  There has been no feedback on that
except for Tom Wu's comment that g=2 is not an appropriate choice for
SRP (unlike IKE).  So that means the IKE groups are not directly
useable because we would have to replace g=2 by g=<a generator> for
SRP. 

I don't know if the objection to g=2 is applicable to DH-CHAP;
unfortunately, that question goes well beyond my crypto skills but
there are others on this list who do have the ability to answer that
question.

The SRP RFC lists several groups, but it does not explicitly state how
they were verified.  It would be good to know that each N was
rigorously tested for primality.

So I would like to see us enumerate a small set of groups, starting at
768 bits and preferably at this time going no higher than 2048 bits at
the very most.  Those groups would be identified in the protocol by an
ID (small IANA implication here?).  That eliminates the complexity
and risk of permitting other groups or pseudo-groups.  For the list of
groups, I'd suggests the SRP list (preferably with the supporting data
I mentioned) and perhaps the IKE groups if there is someone who can
produce appropriate values for g.

Actually, I'd be comfortable with just a single group of size 768;
it's certainly hard to see why putting anything stronger in DH-CHAP
makes sense.  For SRP, I'd argue the same because anyplace that feels
it needs stronger protection will clearly want to use IPsec, and then
the SRP exchange is protected inside IPsec.

    paul