Review Comments: draft-ietf-sacred-protocol-bss-00.txt
Dale Gustafson <dale.gustafson@bpsi.net> Mon, 03 December 2001 16:30 UTC
Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12535 for <pkix-archive@odin.ietf.org>; Mon, 3 Dec 2001 11:30:36 -0500 (EST)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fB3Fd3j28336 for ietf-pkix-bks; Mon, 3 Dec 2001 07:39:03 -0800 (PST)
Received: from mnmai05.mn.mediaone.net (mnmai05.mn.mediaone.net [24.131.1.59]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB3Fd2228332 for <ietf-pkix@imc.org>; Mon, 3 Dec 2001 07:39:02 -0800 (PST)
Received: from bpsi.net (nic-245-c18-151.mn.mediaone.net [24.245.18.151]) by mnmai05.mn.mediaone.net (8.11.1/8.11.1) with ESMTP id fB3FdDu21350; Mon, 3 Dec 2001 10:39:18 -0500 (EST)
Message-ID: <3C0B9CDE.F34E8232@bpsi.net>
Date: Mon, 03 Dec 2001 09:40:14 -0600
From: Dale Gustafson <dale.gustafson@bpsi.net>
X-Mailer: Mozilla 4.78 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@baltimore.ie>
CC: PKIX List <ietf-pkix@imc.org>
Subject: Review Comments: draft-ietf-sacred-protocol-bss-00.txt
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
Content-Transfer-Encoding: 7bit
Hi Stephen,
A few comments on the latest revision of the SACRED protocol specification.
2.1.4 Password Change
Perhaps the terminology can be clarified to differentiate the passwords involved; one password may be needed for the authentication/session security method (when SRP-3 is used in this document); the other (2nd) password is used to derive a secret key that provides persistent encryption for the credential per se.
Some have suggested that server implementations may want to ensure the two passwords are always the same (e.g., for user convenience).
From a security standpoint, it would be preferrable that the server
does not need to have access to the credential password -- or at least
the protocol does not require the server to handle the password in it's
plaintext form for change password (or any other) function.
2.1.5 Credential Upload
The current text uses different forms of the Upload request to; add a new credential, update (replace) an existing credential, or delete a credential. This seems like it could lead to confusion when multiple credentials are being accessed from several internet devices.
Client software should be able to allow the user to clearly see/verify
what they are overwriting or deleting (assuming that such decisions are
not always easily reversed).
2.2 Session Security
Allowing clients to support either authentication/session security method (and requiring servers to support both) is a big workability improvement.
This is of paramount importance for SACRED because fitting all needed
functions into memory constrainedROM or firmware-based internet devices
is often way harder than it looks. We may want to add some words
to that effect.
2.4 Handling Multiple Credentials for an Account
Similar comment to 2.1.5.
Should be possible for the user to manage multiple credentials on a
server in a airly controlled fashion.
3.2 Credential Format
The format for xbulk:pkcs-15 may need to be defined in this document
(if/as needed to satisfy current IETF guidelines for referenced standards).
4. BEEP Profile for SACRED
Stephen mentioned recently that SACRED is using BEEP but the XML groups appear to be committed to SOAP and SAML.
Since the transactions defined in this document are very simple (generally, a one message client request with a one message server reply), it's not clear to me how much elegance we need at the session layer other than setting up a security environment to protect the transaction data during network transfer and clearly identifying the data types.
We began with the simple notion of requiring user login via secure password (or equivalent method) to ensure credentials are delivered to the rightful user and no others. I assume we'd strongly prefer to retain that level of functionality and flexibility.
Is BEEP the right direction here?
5. IANA Considerations
... IANA registers the BEEP profile specified in Section 4
...
6. Security Considerations
No mention of the need to limit password guesses via the network.
We really need to mention the different forms of password guessing that
should be limited by servers.
- Review Comments: draft-ietf-sacred-protocol-bss-0… Dale Gustafson
- Re: Review Comments: draft-ietf-sacred-protocol-b… Dale Gustafson