Subject: Re: [Isms] workinggrouplastcallondraft-ietf-isms-transport-security-model-03

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 18 May 2007 14:20:41 -0400

On Monday, April 30, 2007 09:36:06 PM +0200 Juergen Schoenwaelder 
<[email-masked]> wrote:

> On Mon, Apr 30, 2007 at 11:01:10AM -0700, McDonald, Ira wrote:
>
>> To allow failover to something other than local passwords
>> based on configured policy to be RFC-conformant, but still
>> maximize interoperability, how about adding a SHOULD (rather
>> than a MUST) for failover to local passwords (that explains
>> how it might be at variance with a legitimate local policy)?
>
> Why should we standardize local policy? A fallback mechanism to local
> passwords might even be a security nightmare if those local passwords
> never get changed.
>
> I am find to discuss fallback mechanisms and the pros and cons of them
> but I somehow feel SHOULD or MUST language may go a bit to far.

I agree.  MUST are SHOULD are for implementors; this is a policy decision. 
We can give deployment advice, like "if you want to be able to connect to 
this device when the AAA server is broken or unreachable, don't depend on 
AAA" (or s/AAA/Kerberos/g), but we should go no further.  The right thing 
to do here really depends on the situation, how important the device is, 
what authentication methods are in use, and so on.

To be clear, I interpret the requirement as stating that the TSM must not 
be designed such that it only works when AAA or some similar service is 
available.  I believe it would be entirely acceptable to have a security 
model which sometimes depends on AAA, depending on how it is configured. 
But this is rather moot, as the TSM does not depends on AAA at all, ever.

A secure _transport_ model may depend on AAA, but that is a different 
question entirely.  The SSH transport model document happens to specify 
basically the same constraints, and again, I believe that it is acceptable 
to have a transport model which sometimes depends on AAA or another network 
service, depending on how it is configured.  The SSH transport model 
actually falls into this category; some SSH authentication methods depend 
on external services (e.g. GSS-krb5), some do not (publickey), and some may 
or may not, depending on how they are configured (password could use local 
passwords or AAA or some other mechanism; keyboard-interactive could do any 
of those or a variety of other things).

In the case of a transport model, I happen to think a less stringent rule 
is appropriate.  In particular, I see no problem with secure transport 
models that _always_ depend on some external network service, as long as we 
define at least one that can be configured to work in times of network 
stress.  The requirement is that I be able to authenticate to and manage my 
network devices when the network is broken; it is not that every possible 
way of authenticating to and managing my devices works when the network is 
broken.

-- Jeff

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms