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

["Chris M. Lonvick" <clonvick@xxxxxxxxx>]

Hi Stephen,

At 11:42 AM 10/11/00 +0100, Stephen Farrell wrote:

>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:-)

Maybe I'm just odd as well, but I like having a greater priority 
than a machine.  :-)


>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? 

That scenario would be unrealistic as I agree that there needs to
be some level of user involvement.  As I said before, that situation 
may be an unsolvable problem.  

On the other hand, here is a scenario that I think is realistic and 
demonstrates an acceptable use of sacred.  It does require the 
intervention of a person acting in the role of the owner.
  Once upon a time, a router generated a keypair.  The administrators
  transferred the public key of that router to a lot of other (peer)
  routers and used that router to encrypt traffic to the other routers.  
  ..and this was good for many years.  Then one day, the network 
  administrators found that this particular little router couldn't handle 
  an OC-192.  So they trashed it and replaced it with a really big router.
  While they were there, the craft workers inserted a smart card into the 
  router and logged into the router.  They give the appropriate commands 
  and entered the correct answers and so the credentials (keypair) were
  transferred to the new, big router.  Alternatively, the craft people
  could have logged into the router, given it a minimal configuration
  and transferred the credentials from the credential server to the
  router.  They would have to perform the correct incantations and
  authentications for the transfer to be successful.  In this way, the
  identity of the router was moved from an old router to a new one.
  The administrators were glad that they didn't have to edit the
  configurations of all of the peer routers as well.


>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? 

I fully agree.  There are major security concerns there which is
why it may be unsolvable at this time.  Let's agree to not go there.

>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 think that it's along the lines of "Betamax v. VHS".  If a good, open
standard can be built, then I don't want to go down a proprietary path.

At some future time when this group finishes its work, I'd like to be
able to say, "Cisco routers and switches can securely transfer their 
credentials in the method described in RFC-xxxx."  If the wording in
that RFC clearly states that the credentials belong to a person (unique
individual) and only that person can manipulate the credentials, then
I won't be able to truthfully say that.  If the wording is a bit looser,
then we'll have a solution that fits more scenarios such as the one I
describe above.


>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.

Let me know if the scenario above fits the bill.


>- 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? 

           -----------------------------------------
           |                   |                   |
           |    We currently   |                   |
           | have no solution  |      sacred       |
           |                   |                   |
           -----------------------------------------
                               ^
       the line _______________|

:-)  We are capable of a proprietary solution but I don't think that is
what we want to offer.  Given the option, I would prefer to say, "If you
want to transfer the credentials of a router to another router, then go
get the same stuff that you would use to transfer your credentials from
your laptop to your cell phone."  


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

Not in any way that I can see.  I need to do a more thorough review,
but I can't see that there are any differences in the functionality of
what you propose and what I would like.  I honestly think that we're
discussing a bit of interpretation about the definition of the ownership 
of the credentials.  A strict interpretation would say that the
credentials are totally associated with a unique individual.  A looser
interpretation would allow the association of the credentials to a 
device.  In the case of an individual transferring the credentials,
the individual would have to perform the tasks.  In the case of the
transfer of credentials of a device, the tasks would have to be 
performed by someone acting in the role of the owner - the operator
or administrator.

I think that the work of this group as it is chartered and outlined in
the draft can be applied to devices and roles and not just to individuals
and their credentials.  I'd like for that to be part of the IDs.



>Regards,
>Stephen.


Thanks,
Chris


>"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.
---remainder deleted for brevity---