OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [kmip] Groups - Client Registration (2)(kmip-1.0-spec-client-reg-d.doc) uploaded


Hi Denis,

Thanks for addressing my comments. Please see my responses [IF] inline.

Regards,
Indra

-----Original Message-----
From: Pochuev,Denis [mailto:Denis.Pochuev@safenet-inc.com] 
Sent: Wednesday, May 18, 2011 5:34 PM
To: Fitzgerald, Indra; 'kmip@lists.oasis-open.org'
Subject: RE: [kmip] Groups - Client Registration (2) (kmip-1.0-spec-client-reg-d.doc) uploaded

Indra,

Thank you for reviewing the proposal and providing valuable feedback.

I will work on the updates to the Usage Guide, providing examples and updating the sections you've mentioned.

My comments and answers to your questions are below (marked with [DP]).

Regards,
Denis

-----Original Message-----
From: Fitzgerald, Indra [mailto:indra.fitzgerald@hp.com] 
Sent: Tuesday, May 17, 2011 5:19 PM
To: Pochuev,Denis; kmip@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.

The information contained in this electronic mail transmission 
may be privileged and confidential, and therefore, protected 
from disclosure. If you have received this communication in 
error, please notify us immediately by replying to this 
message and deleting it from your computer without copying 
or disclosing it.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]