[Ietf-keyprov] RE: KeyProv Scope

[Shanmugam, Murugaraj]

 Hi Phillipe,
 
Thanks for your reply. Comments/answers inlined:
 
 
 >>  I am not quite sure what you are arguing for here or whether you
are arguing for something to be in or out of scope.
 >>  Could you clarify whether you are proposing something you want to
do or something you think people might want to do but should not?
 
I would like to clarify my understanding (or misunderstanding) about the
overall goal/scope of KeyProv. This work seems interesting to me.
My question was: " How the validation phase for the Provisioned key will
happen"? will the keyprov take care of it or not?
 
 >> One would hope that the key once provisioned would remain in the
device regardless of application. This is not always possible to
>>  guarantee   (secure hardware, etc.) but generally one would expect
it to be provisioned to one device and stay there and if you needed a
key  >>  in a different device provision to that device. 
 
I agree 
 
 >>  Once provisioned the scope of KEYPROV ends. Whether they are used
for symmetric key authentication tokens (e.g. OTP,  
>>  challenge/response) or DNSSEC or BGPSEC or whatever is not in scope
for the protocol except insofar as the only clearly defined  
>>  deployment community to date is for symmetric key authentication
tokens.
 
Good, that answers my question, You say that once the key is provisoned,
the keyprov scope ends. But previously, I had the feeling that the
validation of the provisioned key was also in the scope.
 
 >> The way I see it there is a big difference between a key
provisioning protocol and a key exchange protocol like Kerberos,  
>> WS-SecureConversation,     IKE etc. In a key exchange protocol your
starting point is some pre-established set of keys. In a provisioning   
>> protocol the point is to establish those keys. 
 
True.  My guess is that the KeyProv faciliates only one point of contact
for the end user to obtain the necessary keys and then you do whatever
mechanism (with whomever ;) ) you like, using  that key. This will help
the user to minimize the need to establish pre-shared keys with other
parties.
 
While you could use a sufficiently general provisioning protocol to do
all your key provisioning and key exchange needs I don't think that
makes a lot of sense. We have good key exchange protocols and these are
already well defined as is their relationship to the applications that
employ them.  
 
I agree
 
I don't see a need to repeat that work, but I don't see a need to come
out with an explicit statement that the KEYPROV protocol must not be
used in that situation or worse that we be required to design KEYPROV in
such a way as to prevent it from being used in that fashion. I don't
expect that last one to come up in KEYPROV but I have seen it come up in
the past.
The point at this time is to focus on the charter, not the use cases. If
there is a rat hole that must be avoided then it would be appropriate to
mention that in the charter. If on the other hand the concern is that
people might do something unfortunate with the final result that would
be appropriate for an applicability statement or a security
considerations. A charter is not a tutorial, it is a Statement Of Work
intended to be read by a very specific audience. 
 
 
ciao,
Raj.


________________________________

	From: Shanmugam, Murugaraj
[mailto:murugaraj.shanmugam at siemens.com] 
	Sent: Monday, November 20, 2006 3:48 AM
	To: ietf-keyprov at safehaus.org
	Cc: Hallam-Baker, Phillip
	Subject: KeyProv Scope
	
	

	Hi, 

	I have a few questions relsted to the scope of KeyProv: 

	1. If a user obtains a symmetric key using the "KeyProv"
protocol, is it possible to use only within the device (say, S/Ws
running) or is it intended to use with other Application Services (e.g.,
a third party service via the Internet)? (of course assuming appropriate
relationship between the Provisioning server and the TTP).

	2. If the later applies, will the "KeyProv" handle the protocol,
between the TTP and the provisioning server, which faciliates the
verification?

	Thanks 

	Ciao, 
	Raj. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.safehaus.org/pipermail/ietf-keyprov/attachments/20061121/a809d23a/attachment-0001.html