Re: Some Thoughts on draft-arsenault-sacred-reqs-00.txt

[Stephen Farrell <stephen.farrell@xxxxxxxxxxxx>]

Hi Chris,

I wouldn't have a problem with catering for devices in addition to 
people, but would note that the charter does specifically talk 
about end users and doesn't specfically mention devices, so I 
think if there were ever to be a conflict the people beat the 
machines! (Comforting, eh:-)

Having said that, I'm not sure there's that much conflict, but
have the following questions:

- Can you describe a scenario in which there's no user involvement
at all whilst the sacred protocol is being used and adds value? I 
guess there would be some security concerns - if the device can't 
store the credential securely through say, a boot cycle, then how 
can it securely store the authentication information needed to get 
the credential back? Also some applicability issues - since devices 
don't have a problem with long passwords, where's the need for 
sacred? (I.e. why not just have the device encrypt the credential 
in a proprietary format outside and reload as needed?) 

I'm not saying there aren't good answers, but a scenario that clearly 
demonstrated the benefits of sacred while answering the above would be useful.

- Where do you draw the line between private key backup as provided 
by all decent crypto hardware, (e.g. typically onto smartcards or 
tokens) and use of sacred? 

- Other than the examples, does this impact on the requirements
posited in the draft? If so, how?


Regards,
Stephen.

"Chris M. Lonvick" wrote:
> 
> Hi,
> 
> I've been having some thoughts about credentials from a different
> angle.  I'd like to express them here for some discussion.
> 
> In section 1.1, and in the proposed charter, the examples deal with the
> mobility of credentials as they relate to people.  I'd like to suggest
> that there are credentials that are exclusively associated with devices
> that still require some amount of mobility.  I have started calling the
> credentials of a device its' "identity".  For example, a Unix device may
> be running sshd in which case it has a public RSA key that it can
> present.  All ssh sessions initiated to that server should expect to see
> the same credential and will then know that it is the same Unix device.
> Let's say, however, that the poor Unix box is struck by lightning before
> a backup could be made of the keys.  When the device is replaced, a new
> key-pair will have to be generated and all ssh clients attempting
> sessions to the "new" device will have to be informed that the "identity"
> of the device has changed.  It would have been far better if the key-pair
> had been backed-up.  In that case, when the new device is installed, the
> credentials could be placed in it so that it could assume the identity of
> the wrecked device.  Then, other devices attempting ssh sessions to it
> would recognize it as if it had never been replaced.  This is a case of
> archiving the identity of a device so that it may be resurrected in the
> case of a catastrophic failure.
> 
> Another case for the mobility of credentials is for the duplication of an
> identity.  Let's say that I set up an e-commerce site with one web server
> that becomes wildly successful.  I may choose to place more servers behind
> a load-balancer.  In that case, it would be nice to have the same X.509
> certificate on each of those servers for SSL.  I would like to be able to
> securely transfer the certificate from some device to each of the web
> servers.
> 
> In both of these cases the identity of a device may be easily moved from
> one device to another.  I can do the same for the identity of my laptop; I
> have copied my PGP keyring from my old machine to my new machine.  However,
> this ease is only available at a small scale.  Consider that each router
> and switch in a large network may have an X.509 certificate that it uses
> for IPsec.  The same could be said for each "server" type of machine in an
> administrative domain.  The network administrators would not like to
> provision each of those individually.  Also, in the case of my PGP keyring,
> I transferred it via a floppy.
> 
> The idea of dynamically transferring a keypair to each router claiming to
> require it (similar to downloading an image or configuration via tftp)
> does not appeal to me.  ;-)  I don't think that is a problem that needs to
> be addressed by this group, and it may very well be unsolvable.  On the
> other hand, in the case that a router is taken out of service, I would
> like for the operators to be able to download the correct key-pair to that
> router in a secure method.  In some cases, that may be preferable to
> revoking the certificate of the removed device.  I don't think that the
> network operators really want to physically touch each router for that
> transfer of its "identity".
> 
> I think that the bottom-line to all of this is, if no one vehemently
> disagrees, that the examples in the draft become slightly less "user"
> focused and that the group keeps in mind that credentials are not always
> coupled with a person.  I don't think that this diverges from the intent
> of the charter or of the draft.
> 
> Comments welcome.
> 
> Thanks,
> Chris

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:stephen.farrell@xxxxxxxxxxxx
Ireland                             http://www.baltimore.com