Re: [Isms] WGLC: draft-ietf-isms-radius-usage-02

["David Harrington" <ietfdbh at comcast.net>]

Hi,

comments inline. 

> -----Original Message-----
> From: David B. Nelson [mailto:d.b.nelson at comcast.net] 
> Sent: Wednesday, April 02, 2008 10:12 AM
> To: isms at ietf.org
> Cc: 'David Harrington'
> Subject: RE: [Isms] WGLC: draft-ietf-isms-radius-usage-02
> 
> David Harrington Writes...
> 
> > I am only suggesting that the design of the document should be
that
> > it is specifically an SNMP mapping to these documents, as if there
> > were also CLI mapping documents and Netconf mappings documents,
etc.
> 
> OK. I understand.  You want us to design the document 
> following an SMNP-like
> architecture, with abstract subsystems and concrete models.  
> Personally, I
> think that's asking a bit much, but we'll see what we can do.

No. I am not suggesting any sort of architectural design with abstract
subsystems or anything else.
I find the document hard to read for a number of reasons.
One of the biggest is that, at times, it feels like a promotional
brochure for your attributes, rather than a technical discussion of
how to utilize those attributes in an SNMP environment. That was my
point about writing from the viewpoint that they have already been
approved for use; stop trying to sell them to us; tell us how to apply
them.

> 
> > My objection is to the use of "recommended".
> 
> Hmmm.  "RECOMMENDED" is an RFC 2119 keyword, synonymous with 
> "SHOULD".  From
> that RFC:
> 
> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that
there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course.
> 
> > Recommending is what you do when you're trying to sell something.
> 
> So, we should issue an errata against RFC 2119?  :-)

If you are using recommended as an RFC2119 keyword, please capitalize
it so it is clear that is the way you intended it to be interpreted. 

> 
> Seriously, though, it's in the "RECOMMENDED" sense that I used
> "recommended", but I think we can easily wordsmith the text you find
> confusing to fix that issue, perhaps just substituting 
> "SHOULD".  Consider
> it done.

good. I am not certain that this document should be saying SHOULD for
attributes defined in a different document however. If they do not use
the management attributes, then this document would make little sense.
I will wait until I see how you reformulate this.

> > I think the Management-Policy-ID, and the Transport-Protection
> > attributes should be captured by an SNMP Transport Model, and
stored
> > in the SNMP LCD as part of the transport-specific information
> > received. This will make it available for later use by 
> access control
> > models.
> 
> Is this an "Implementation Note"?  Is it your intent that 
> this document
> places this requirement on the SNMP engine implementation?

We have a problem in ISMS. We are expected to folow the RFC3411
architecture modularity, yet we need to pass provisioning information
acquired during the RADIUS authentication and service authorization
phase to the access control phase. The ASIs do not support this. If we
do not capture this informaton in a predictable manner, then no ACM
will know where to find this information.

Unfortunately, we don't define any way to pass this information, and
we don't concretely define what is in the LCD, so we cannot be very
clear about how this information gets captured and made available to
ACMs. The closest we come is to say that the LCD contains information
recorded by the transport model received from the transport layer. 

So I suggest we provide an implementation note that says "you can
record this provisioning information in the LCD, in an
implementation-specific manner", and then later, when we write an ACM
to utilize RADIUS info, we can say something like "the ACM checks to
see if there is provisioning information in the LCD related to this
securityName" or some such hand-waving.

> 
> > I suggest making the isms document SNMP-like, and the 
> radext document
> > RADIUS-like.
> 
> Sounds nice, but I'm not sure I'm up to the task.  :-(

I'll help by pointing out things I find "unusual" in a document.

> 
> > Yes, it's not the completeness or correcetness I have concerns
with.
> > There are some open issues in ISMS, and this paragraph may change
as
> > we resolve those open issues.  We need to discuss this further.
> 
> OK.  Are you suggesting that the RADIUS Usage document cannot 
> be competed
> until the remaining issues in the other ISMS documents are resolved?

Yes. 

> 
> > In addition, there are some other issues with SNMPv1/v2c 
> that may come
> > into play if the radext attributes do not support specifying a
> > particular SNMP transport model or a specific transport protocol
> > (which would permit us to assume which specific SNMP transport
model
> > is involved):
> > 
> > > > Currently, SNMPv1 can be used with an SSH tunnel, with no
> > > > transport model to provide a binding; we might develop 
> a transport
> > > > model with a binding. The RADIUS attributes for 
> management, however,
> > > > may not allow us to choose which transport model or even which
> > > > transport protocol, and under those conditions, I don't 
> know what
> > > > we have for security with an SNMPv1 or SNMPv2c (or 
> SNMPv3) message,
> > > > since we may have no transport model to provide a 
> mapping between 
> > > > the transport layer credentials and the SNMP-specific 
> > > > securityModel/Name/Level.
> > 
> > This also will require further discussion.
> 
> OK. Let's start a discussion of that.  I don't think that 
> having the RADIUS
> Server, and the system administrator, specify particular 
> transport protocols
> and granular security parameters of such protocols is 
> ultimately useful.  It
> is certainly possible to define RADIUS attributes to do that, 
> even if it
> turns out there are a large number of them and it takes us 
> quite a while to
> define them correctly.  My concern is that it will be hard for an
> administrator to apply them correctly.  Of course, RADIUS Server
> implementations could be created with wizards and other UI features
to
> assist in creating correct configurations.  I'm just not sure 
> that's where
> we want or need to go.
>
Back around 1995, there was a suggestion to "just use IPsec".
That wasn't possible because IPSec has no "northbound" interface to
pass information to the upper layers, such as which identity was
authenticated, and which type of IPsec was used.

Around 2001, Jeff Schiller started giving Sunday tutorials on why it
is was unacceptable to say "just use IPsec" or "just use" other lower
layer protocols; it is important to specify how you will actually
communicate between the lower layer and the application.

I am concerned that dropping the choice of transport protocol really
limits how we can communicate with the lower layer to get information
we need to determine what level of access control should be applied.
"any protocol that provides transport layer encryption" may not be
good enough for operators.

But we can discuss this further on the list.

David Harrington
dbharrington at comcast.net
ietfdbh at comcast.net
dharrington at huawei.com


_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms