-----Original Message----- From: Fitzgerald, Indra [mailto:indr...@hp.com] Sent: Tuesday, May 17, 2011 5:19 PM To: Pochuev,Denis; km...@lists.oasis-open.org Subject: RE: [kmip] Groups - Client Registration (2)
(kmip-1.0-spec-client-reg-d.doc) uploaded

Hi Denis,

I reviewed the spec changes and the updated proposal. Please see my comments
below. Additional clarification and guidance should also be added to the Usage
Guide, including examples. In addition, we need to update sections 3.1
(Authentication) and 3.1.1 (Credential) of the Usage Guide.

Thanks, Indra

Spec changes:

1. Line 224 mentions that the Transport Certificate Credential Types instructs
the server to extract the transport certificate (e.g.; TLS client certificate)
and derive the client's identity from it. The TLS handshake occurs prior to
exchanging any KMIP messages. During the handshake, the server wouldn't know
whether it is required to extract the client's identity from the transport
certificate. The server becomes aware of any entity authentication requirements
after successfully establishing a TLS session. What exactly is expected from the
server? [DP] I am not sure why you conclude that "the server becomes aware of any entity
authentication requirements after successfully establishing a TLS session". The
server should be configured prior to any client connection to extract a certain
part of the certificate and identify entity based on this data.

[IF] It depends on how the server is configured. A client may be authenticated
using different types of credentials. We cannot assume that all clients will
include the client identity in the client certificate. One client may use the
username inside the username and password credential, while others may use the
identity provided inside the certificate. Even if the client identity is
specified inside the certificate, it does not mean that the server will use this
to determine the identity of the client. The client may only use the
username/password credential to authenticate the client. In this scenario,
mutual authentication is performed by default as required by KMIP and any
additional authentication is performed using the username and password. The
identity specified inside the certificate will be ignored by the server.

Also, when specifying the Authentication structure in the Message Header and
specifying Credential Type Transport Certificate, no additional authentication
will be performed by the server since the TLS session has already been
established. [DP] That is correct. Using transport Certificate credential type implies that
the only authentication of the client is the one performed by the transport
protocol.

2. Line 483 mentions that Username and Credential certificates SHALL be unique
within a given a key management domain. Does this only apply to Credential
certificates? Does this mean that if clients do not explicitly specify a
transport certificate as a credential, the certificate does not have to be
unique? [DP] Yes, this line does not make a lot of sense. The intent is to ensure the
uniqueness of the Entity given its credentials, where the credentials are the
actual Credential attribute and the management domain. How does this sound
instead: "Username or Credential certificates SHALL be chosen such that it is
possible to uniquely identify the Entity given its Credential attribute and the
management domain." [IF] How about simply replacing "Usernames and Credential certificates" with "A
client's identity"? As in "A client's identity SHALL be unique within a given
key management domain, but are not REQUIRED to be globally unique". We could
include examples, such as the password or the identity specified inside the
transport certificate.

3. Table 68: Allows Get Attributes and Get Attribute List to all. This means
that anyone can have access to the credential attribute(s). Do we want this? [DP] Objects in this table are public by definition. I don’t think it makes
sense to restrict Get Attributes and Get Attribute List operations. [IF] Clients can easily determine how other clients authenticate to the server
and view all the other attributes that are set for an entity. This does not
sound like a desirable feature to me. Also, I assume the password will not be
returned during Get Attributes?

4. Line 1003: What is the purpose of the Entity Identifier? Additional
clarification is required in the spec and guidance in the Usage Guide. [DP] Currently Entity Identifier is used emulate "who am I?" operation. In the
future, it could be used to locate "special" entities. For example, list all
administrators. I agree, it's not crystal clear from the description: "The Entity Identifier
field is used to locate Entities with special properties, such as the currently
authenticated Entity." But I'm not sure how to re-phrase it to make it more
clear. [IF] We can add the clarification in the Usage Guide.

5. For consistency, the Rules table for certain attributes (e.g., Entity
Operation Policy Name and Entity Identifier) should say "Entity Objects" instead
of "Entity" [DP] Yes, thank you for pointing it out.

Proposal comments:

Slide 5, implicit self-registration with cert: It is not clear from the example
what exactly is being performed. If you are creating an entity, shouldn't you
perform a Register? [DP] The idea behind implicit registration is that there is no separate Register
operation for an entity. Entity registration happens as a side-effect of another
operation.

[IF] I would need to think about this one. The client would need to be able to
authenticate to the server during the TLS handshake. So we are assuming that we
already have this setup. In your example, you are implicitly creating an entity
during the Create and by default it sets the Transport Certificate as the
Credential? This doesn't sound right. Perhaps you can clarify this example
during the call tomorrow.

During the first Create Object, the entity is not being authenticated; during
the second Create Object, authentication is performed using the transport cert
(although the TLS session has already been established). [DP] In both cases the Entity is authenticated using the transport certificate,
since this is what always happens. In some sense adding an empty Credential
Value is superfluous. This is something I wanted to bring up during the phone
conf. Should the Credential with an empty value be omitted from the
Authentication header? In other words, by default assume that authentication is
performed based on the transport certificate.

Slide 7: What happens if multiple credential attributes are specified for the
entity (password and certificate)? [DP] Would it be during registration or authentication? If an Entity has
multiple credentials, I think it should be up to the server policy to require
all (or some) credentials for successful authentication. [IF] During authentication.

Slide 10: Can the name attribute of an entity and the username specified inside
the credential attribute be different? [DP] That is a great question. It would probably be easier for users if they
were the same, but technically there is no reason why any restrictions should be
placed on the Name of the Entity other than those placed on the Name of any
Object. Note that currently Entity is not required to have a name. This is where
the Name equals username assumption would break. [IF] We may need to discuss this during the call.