Subject: Re: SRP CP/IP/RD options

From: [email-masked]
Date: Sat, 2 Feb 2002 19:58:38 +0200

SRP authentication is done once. Encryption and integrity protection
are done for every message. Our thinking is that deployers should
have the option to avoid the extra hash in situations where it may be
unnecessary eg. where there are message size or speed constraints.

The option of having confidentiality without integrity is a policy decision,
and we have already been reminded that we can't prescribe policy to
deployers.

However, we do agree that deployers should be encouraged to do
the "right thing" in general. So, we plan to specify:

   - the server MUST advertise at least one integrity protection algorithm
   - the server SHOULD always send the "mandatory=integrity" option
   - the client SHOULD select integrity protection, even if the server
     doesn't make it mandatory to do so

where SHOULD is defined as per RFC 2119:

    SHOULD  This word, or the adjective "RECOMMENDED", mean
    that there may exist valid reasons in particular circumstances to
    ignore a particular item, but the full implications must be understood
    and carefully weighed before choosing a different course.

This means that
   - normally integrity protection will be active
   - if you select confidentiality, you should also select integrity
   - you CAN select confidentiality without integrity but it is not
     recommended and you must understand the consequences

 - Keith and Raif

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 02 Feb 2002 10:18:52 -0800

>   - the server MUST advertise at least one integrity protection algorithm

The implementations (client or server) MUST support the XXYYZ
integrity protection algorithm.

>     recommended and you must understand the consequences

These consequences should be discussed in the I-D, likely
in the security considerations section.

---

From: [email-masked]
Date: Sat, 2 Feb 2002 19:58:38 +0200

This means that

 - Keith and Raif

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 02 Feb 2002 10:18:52 -0800