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

From: "David B. Nelson" <[email-masked]>
Date: Tue, 1 Apr 2008 15:44:15 -0400

David Harrington writes...

> I have reviewed this document. Comments below.

Thank you for your thorough review.  I will respond to those issues that are
easily resolved and highlight those which require further thought or
discussion.

> I found the document a little hard to read because background info on
> RADIUS, info on the management-policy-id related attributes, and the
> mapping to SNMP are all mushed together.

This is something that will require further thought.  The authors added the
introductory material in response to your comments on a previous version.  A
plan to more clearly delineate the various elements will require some time
spent in re-reading the material with an eye toward that objective.

> In discussing the mapping to SNMP, PLEASE assume that the
> management-policy-id has already been accepted by the IETF.

Sure.

> That means a lot of the phrases like "RADIUS servers compliant to this
> specification" can just be reduced to "RADIUS servers".

I think you misunderstand the intent of that phrase.  It has nothing to do
with the status of the document (draft or published RFC) and everything to
do with the fact that there is no monolithic RADIUS Standard.  There is the
base RADIUS protocol and there are number of optional extensions, supporting
specific applications.

> So, I recommend the document have sections 1) introduction to standard
> RADIUS, 2) introduction to the management-policy-id and related
> attributes, and THEN discuss the mapping to SNMP (Actually, I would be
> fine with having the first two combined or possibly eliminated).

Well, as to the possibility of eliminating the introductory material, it's
largely there at your request.  :-)

> I think this document should be written as one of multiple mapping
> documents for the management-policy-id and related attributes, and it
> should be expected that a mapping document will be done at some point
> for Netconf, the CLI, and potentially other interfaces. 

Hmmm.  That sounds like scope-creep.  I agree that we should avoid creating
any gratuitous SNMP-specific dependencies, but this document is about RADIUS
and SNMP, not about RADIUS and anything else.  Right?

> 1. I recommend moving the "Requirements language" text into a section,
> possibly under Introduction.

I'll need to review the draft to identify this text, but the suggestion
sounds very reasonable.

> section 1.1 - we don't have modules in ISMS, we have models and
> subsystems.

I always think I've got rid of the last of those, but I probably introduce
new ones at the same time as eliminating old ones.  :-)  We'll take care of
this.

> section 1.2 says "An Access-Reject message indicates unsuccessful
> authentication." Does it also indicate an unsuccessful authorization?

Yes.

> section 2 says
>    "Service authorization allows a RADIUS server to authorize an
>     authenticated principal to use SNMP over a specific secure
>     Transport Model.
> I think that is incorrect. The attributes we intend to use here
> authorize the use of a service for Framed-Management, the
> Framed-Management-Protocol to use (SNMP), a Management-Policy-ID (such
> as "Operator"), and a level of Transport-Protection.

Yes.  That's a mouthful (run-on sentence) but that's really what's meant.

> section 2 discusses PAM; how do RADIUS servers in a Windows
> environment do this?

PAM is an interface between an end-user data service (e.g. SSH) and an
authentication service (e.g. RADIUS Client).  RADIUS Servers do not come
into the picture.  PAM is common in Unix environments.  I don't know what
the equivalent is in a Windows environment.

> s/rely of/rely on/

OK.

> section 2.1
> "Specific attributes for use with SNMP Transport Models are
> recommended in this document." I don't think this document should be
> used to make recommendations of specific RADIUS attributes. This
> document should simply be about how to use the management-related
> attributes that are defined, in an SNMP environment.

Huh?  You want this document to describe how to use RADIUS for
authentication and authorization of SNMP access without mentioning specific
RADIUS attributes?  I know that SNMP documentation and architecture is big
on abstraction, models, and such.  RADIUS documentation doesn't go in for
that sort of thing, for better or worse.  I wouldn't know where to begin...

> s/"RADIUS servers, compliant to this specification, MAY use RADIUS
> hint attributes, as described herein, to inform the decision whether 
> to accept or reject the authentication request."/
>   "RADIUS servers MAY use RADIUS hint attributes to inform the
> decision whether to accept or reject the authentication request."/

OK.  You don't like my overly-formal language.  I can live with that.

> (but isn't the hint really part of an authorization request rather
> than an authentication request?

You can't really separate the two in RADIUS, as much as one might like to.
I know this has been an issue in the ISMS work, but RADIUS is a legacy
protocol and "it is what it is".

> I might be able to authenticate who I am, but still not get approval
> to access the SNMP service.")

That's true.  In that case one of two things would happen.  The RADIUS
Server would return an Access-Accept message provisioning a default service
for your profile that you are authorized to use, or more likely the RADIUS
Server would return an Access-Reject message, because you are not authorized
to use the service you are apparently requesting. 

> section 2.2 eliminate the sentence
> "   Specific attributes for use with SNMP Transport Models are
>    recommended in this document."

This gets back to my previous question.  Are you effectively asking the
authors to create an abstract "model" of how RADIUS might interact with
SNMP?  I don't think that's what we have been tasked to produce.  If that's
not what you're asking of us, what is your concern with specificity? 

> "   The following RADIUS attributes MAY be optionally used, to
> authorize use of SNMP over the default UDP transport protocol (no
> privacy):"
> What transport model calls RADIUS to authenticate a UDP session? This
> is news to me.

Hmmm.  That looks wrong.  I forget where that came from, but it will be
removed.
 
> "   The following RADIUS attributes are used to limit the extent of a
>    secure transport session carrying SNMP traffic, in conjunction with
>    an SNMP Transport Model:
> 
>    1.  Session-Timeout
>    2.  Inactivity-Timeout."
> What transport model does this?

Well, I'm not sure any of them do...  more like they should.  I think this
needs some discussion.

> I think this is between RADIUS and the transport protocol that is
> using RADIUS, such as SSH.

Quite possibly.

> I don't think SNMP has anything to do with this, and there is no 
> place in the ISMS architecture to specify these values.

There may not be a place in the ISMS architecture.  However, RADIUS has a
long history of provisioning limits on the services that it authorizes, so
it seemed natural to continue this practice with SNMP.

> I am not sure they should be discussed in this document.

If not here, then where?

> Is this Inactivity-Timeout related to the Idle-Timeout mentioned
> later?

Yes.

> section 2.4. I think the authorization attributes provided by RADIUS
> should probably be captured as part of the LCD, as part of
> transport-specific information.

I don't understand.

> section 3 should be part of the introduction to RADIUS and the
> management related attributes. It seems out of place here.

Well, in RADIUS documents there is always a Table of Attributes near the end
of the document, just before such sections as the Security Considerations.
In case it's not already apparent, the authors are following RADIUS document
style and not SNMP document style.

> section 5
> s/Threats and security issues for
>    this application are described in [RFC3579] and [RFC3580]; "
> /Threats and security issues for
>    RADIUS are described in [RFC3579] and [RFC3580];/

OK.
 
> Paragraph three discusses selecting SNMPv1 and SNMPv2c. I think the
> discussion of using RADIUS with these needs further discussion.

OK.  I'm sure I got this text from some posting on the ISMS list, but I'm
not sure it's correct or complete.

> 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.
> 
> The "this may not be expected" would probably be better phrased as
> "the authenticated identity used for securityName will not be the
> identity authenticated by RADIUS".

OK.

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 01 Apr 2008 17:22:07 -0400

> the equivalent is in a Windows environment.

To be fair, it is also reasonable for a RADIUS server to use PAM for 
password verification, allowing any of a variety of backends to be plugged 
in.  But as far as the protocol is concerned, that's an implementation 
detail.  For that matter, the use of PAM between an SSH server and RADIUS 
client is also an implementation detail.  It's possible that an SSH server 
uses PAM to support the password or keyboard-interactive auth methods, and 
if so, it's possible that the PAM stack is configured to use RADIUS.  The 
fact that we mention this possibility in a couple of places does not mean 
we are obligated to describe every way in which an SSH server might end up 
being a RADIUS client.

I don't think any change is needed here.

> authentication and authorization of SNMP access without mentioning
> specific RADIUS attributes?  I know that SNMP documentation and
> architecture is big on abstraction, models, and such.  RADIUS
> documentation doesn't go in for that sort of thing, for better or worse.
> I wouldn't know where to begin...

I think I have to agree with David here. :-)

The point of this document is to describe how to use RADIUS to authorize 
SNMP access.  I don't see how we can do that without indicating which 
RADIUS attributes are used for that purpose and what they mean.  We could 
write a document which describes some abstraction for allowing SNMP 
applications to see whatever attributes happened to be provided by the 
RADIUS server, but I don't think that would accomplish our goal for this 
document.

> it seemed natural to continue this practice with SNMP.

I agree.  Note that the SNMP architecture doesn't necessarily need to have 
any place to specify these limits.  This can be handled entirely at the SSH 
layer.  And yes, I do think this document is the right place to discuss 
such things.

-- Jeff

---

From: Kaushik Narayan <[email-masked]>
Date: Tue, 01 Apr 2008 15:39:10 -0700

Please find my reply inline.

> spent in re-reading the material with an eye toward that objective.

<Kaushik>

The introductory text is brief to ensure that we do not end up copying
significant parts of other RFCs and drafts. We probably should avoid
significant work in this area unless people believe that the rest of the
specification is unclear because of missing context in the introduction.

</Kaushik>

> and SNMP, not about RADIUS and anything else.  Right?

<Kaushik>

I agree with David, the approach described in the document could be applied
to other management protocols such as NetConf etc. but that is not the
purpose of this document.

</Kaushik>

> the equivalent is in a Windows environment.

<Kaushik>

The reference to PAM was meant to highlight some of the issues with existing
implementations where the OS-specific interfaces are used by SSHv2
implementations to integrate with the RADIUS client. This potentially
complicates how RADIUS attributes received by the RADIUS client are made
available to the SNMP layer. PAM was merely used as an example and the
intent was not to list each OS-specific interface.

</Kaushik> 

> to use the service you are apparently requesting.

<Kaushik>

Service authorization is a coarse granular method to ensure that access to
the SNMP service is limited to operators/administrators, the RADIUS server
would probably be capable of authenticating the entire set of user's within
an organization.

</Kaushik>

>> I am not sure they should be discussed in this document.

<Kaushik>

Session timers and inactivity timers are commonly used for CLI access for
administration (with RADIUS/TACACS+). The timers may be used by the
transport protocol (sshd, telnetd) or the application spawned
(shell/terminal).

I agree with David that this fairly common and needs more discussion before
we dismiss it.

Regards,
 kaushik

</Kaushik>

---

From: "David Harrington" <[email-masked]>
Date: Tue, 1 Apr 2008 21:54:02 -0400

Hi,

comments inline.

dbh 

> and SNMP, not about RADIUS and anything else.  Right?

Sorry. I didn't mean to be misleading with this. I am not proposing
that ISMS write such documents. 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 mapings documents, etc. The goal is to make this document
clearly focused on the mapping.

> I'll need to review the draft to identify this text, but the 

It's at the end of the Abstract before section 1.

> that sort of thing, for better or worse.  I wouldn't know 

My objection is to the use of "recommended".
This should be about how to map from these specific attributes to
SNMP.
We should not be "recommending" anything, just using them.
Recommending is what you do when you're trying to sell something.

"Specific attributes for use with management protocols are
used in this document." is fine. It removes the "recommended".
 
> protocol and "it is what it is".

I am not complaining about them being bundled together in RADIUS
messages. They are two separate concepts, even if they are mixed
together in RADIUS messages. authenticate is "to prove or serve to
prove the authenticity of", such as an identity. Whereas authorization
is "An approval that is granted to a system entity to access a system
resource." RADIUS attributes used for proving a user's identity are
about authentication. RADIUS attributes that are about the
provisioning of the approved service are about authorization. It would
help if you used the words correctly in text.

> not what you're asking of us, what is your concern with specificity?

I don't have concern with specificity; it is with "recommending". 
I would have less issue with
"   Specific attributes for use with SNMP Transport Models are
    used in this document."
I do not however, believe that the attributes are for use with
specific transport models, just with management protocols in general.
"Specific attributes for use with management protocols are
used in this document." is fine. It removes the "recommended".

> Well, I'm not sure any of them do...  more like they should.  

I'll let you start a thread on that topic.

> > transport-specific information.

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.

> style and not SNMP document style.

OK. This document is not about defining new attributes; it is about
how SNMP should use specific attributes. I suggest making the isms
document SNMP-like, and the radext document RADIUS-like.

> not sure it's correct or complete.

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.

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

> > credentials and the SNMP-specific securityModel/Name/Level.

This also will require further discussion.

David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 2 Apr 2008 10:11:45 -0400

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.

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

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.

> together in RADIUS messages.

Agreed.

> RADIUS attributes used for proving a user's identity are about
> authentication. RADIUS attributes that are about the provisioning
> of the approved service are about authorization.

Agreed.

> It would help if you used the words correctly in text.

I sometimes type one when I meant to type the other, so if you find such a
typo please bring it to my attention.  I fully understand the conceptual
difference.
 
> > Well, I'm not sure any of them do...  more like they should.
> > I think this needs some discussion.
> 

Since others have weighed in on this, I will start another thread.

> received. This will make it available for later use by access control

Is this an "Implementation Note"?  Is it your intent that this document
places this requirement on the SNMP engine implementation?

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

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

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

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.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 02 Apr 2008 10:54:07 -0400

> Recommending is what you do when you're trying to sell something.

Wow.  That is completely not what I thought you were trying to say.

-- Jeff

---

From: "David Harrington" <[email-masked]>
Date: Wed, 2 Apr 2008 10:58:24 -0400

Hi,

I have a bad cold this week, and apparently my review was hard for
multiple people to understad my intentions.

dbh 

> -----Original Message-----
> From: Jeffrey Hutzelman [mailto:[email-masked]] 
> Sent: Wednesday, April 02, 2008 10:54 AM
> To: David Harrington; 'David B. Nelson'; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Isms] WGLC: draft-ietf-isms-radius-usage-02
>

---

From: "David Harrington" <[email-masked]>
Date: Wed, 2 Apr 2008 12:37:39 -0400

Hi,

comments inline. 

> From: David B. Nelson [mailto:[email-masked]] 
> Sent: Wednesday, April 02, 2008 10:12 AM
> To: [email-masked]
> Cc: 'David Harrington'
> Subject: RE: [Isms] WGLC: draft-ietf-isms-radius-usage-02
> 

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.

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

> confusing to fix that issue, perhaps just substituting 

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.

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

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

> assist in creating correct configurations.  I'm just not sure 
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
[email-masked]
[email-masked]
[email-masked]

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 2 Apr 2008 12:59:52 -0400

> how to utilize those attributes in an SNMP environment.

OK.  That's something concrete we can work on.  Thanks.

OK.

> I am not certain that this document should be saying SHOULD for

I see this document as an analog to RFC 3580, which explains how RADIUS
attributes are to be used, applied and interpreted in provisioning network
access using IEEE 802.1X port-based authentication.  The [short] title
"RADIUS Usage for SNMP Transport Models" was chosen to mimic "IEEE 802.1X
Remote Authentication Dial In User Service (RADIUS) Usage Guidelines".
Perhaps if the authors are successful in emulating the layout and style of
RFC 3580 we will have succeeded in creating a more readable document.

> will know where to find this information.

Right.

> securityName" or some such hand-waving.

OK.  I'll add some text to that effect in the next version.  If you have
some particular text you'd prefer to see, by all means send it along.

> > Are you suggesting that the RADIUS Usage document cannot
> > be completed until the remaining issues in the other ISMS documents
> > are resolved?
> 
> Yes.

OK. Then, I guess we need some discussion of that list of open issues you
recently posted to the list.  Folks, can we start that discussion, please?

> authenticated, and which type of IPsec was used.

Yes, a significant disappointment, IMHO.  But I digress.

> communicate between the lower layer and the application.

Right.

> good enough for operators.

I wonder...

> But we can discuss this further on the list.

Yeah, let's start a separate thread on this issue.  I do have some thoughts
and questions on this to share.

---

From: "David Harrington" <[email-masked]>
Date: Thu, 3 Apr 2008 18:30:01 -0400

In thinking about this, SNMP needs to know what "model" is used to
authentication, and it know sthat RADIUS is the "model".

I think SNMP actually doesn't need to know how the encryption is done,
only that it is done. The operator can configure the underlying SSH or
other transport to use the approrpiate authentication and encryption
parameters.

So this may actually be a non-issue.
Do others agree?

dbh

> From: David B. Nelson [mailto:[email-masked]] 
> Sent: Thursday, April 03, 2008 6:02 PM
> To: [email-masked]
> Cc: 'David Harrington'
> Subject: What granularity of attributes do we need for the 
> secure transport?
> 
> We need to have a further discussion of this issue on the 
> list, and I have
> the action item start a thread to discuss it.
> 
> Let's start that discussion now.
> 
> I have a couple of thoughts to start off:
> 
> -- If it turns out that we need something more granular than
> Management-Transport-Protection = {No-Protection | 
> Integrity-Protection |
> Integrity-Confidentiality-Protection} to address the specific 
> needs of SNMP,
> could we at that point in time extend the list of enumerated 
> values for the
> Management-Transport-Protection to include special cases for 
> SNMP?  That
> would eliminate the need to restore the
Management-Transport-Protocol
> attribute which caused a number of difficulties in terms of
management
> transports other than those used for SNMP.  Once you specify 
> the protocol,
> then you logically need to specify all sorts of other 
> protocol and security
> related parameters.  I think we don't want to go down that path.
> 
> -- Why do we think that RADIUS authorization should be used 
> to provision
> specific secure transport properties, such as protocol, cipher
suite,
> authentication mechanism, certificate chains, etc?  It seems 
> to me that
> these choices, while important to get right, do not need to 
> be conveyed on
> each and every user access to the managed entity.  They would 
> typically be
> configured and left static for long periods of time.  Yes, it 
> is required
> that both ends of any such connection agree on the 
> parameters, but it seems
> RADIUS authorization is not the optimal way to ensure that.  
> I think that
> the choice that needs to be made on an access by access basis 
> is simply
> whether or not the access needs to be secure.
> 
> 
>

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 3 Apr 2008 18:02:19 -0400

> good enough for operators.

We need to have a further discussion of this issue on the list, and I have
the action item start a thread to discuss it.

-- If it turns out that we need something more granular than
Management-Transport-Protection = {No-Protection | Integrity-Protection |
Integrity-Confidentiality-Protection} to address the specific needs of SNMP,
could we at that point in time extend the list of enumerated values for the
Management-Transport-Protection to include special cases for SNMP?  That
would eliminate the need to restore the Management-Transport-Protocol
attribute which caused a number of difficulties in terms of management
transports other than those used for SNMP.  Once you specify the protocol,
then you logically need to specify all sorts of other protocol and security
related parameters.  I think we don't want to go down that path.

-- Why do we think that RADIUS authorization should be used to provision
specific secure transport properties, such as protocol, cipher suite,
authentication mechanism, certificate chains, etc?  It seems to me that
these choices, while important to get right, do not need to be conveyed on
each and every user access to the managed entity.  They would typically be
configured and left static for long periods of time.  Yes, it is required
that both ends of any such connection agree on the parameters, but it seems
RADIUS authorization is not the optimal way to ensure that.  I think that
the choice that needs to be made on an access by access basis is simply
whether or not the access needs to be secure.

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 3 Apr 2008 17:41:20 -0700

Hi -

> From: "David Harrington" <[email-masked]>
> To: "'David B. Nelson'" <[email-masked]>; <[email-masked]>
> Sent: Thursday, April 03, 2008 3:30 PM
> Subject: Re: [Isms] What granularity of attributes do we need for the securetransport?
>
...

As far as securityModel and securityName as used together in VACM,
I'd agree.  HOWEVER, securityModel is also used together with 
securityLevel (recall our wonderful ASCII art in section 3.1 of RFC 3415)
to describe how information was (or will be) protected in transit, and
this is an important factor in deciding whether to grant access.

The strength of encryption provded by a given security model when the
securityLevel is authPriv must be taken into account when formulating
an access control policy.  Consequently, from the choice of securityModel
one needs to be able to, at the very least, infer what the minimum level
of protection provided by authPriv would be.

So I disagree with the assessment of this as a non-issue.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 4 Apr 2008 13:22:01 +0200

> of protection provided by authPriv would be.

I like to point to the minutes of the ISMS meeting at the 64th IETF
<http://tools.ietf.org/wg/isms/minutes?item=minutes64.html>:

 [12] There was some notion in the room to allow SSH to always provide
      auth/priv services, even in cases where less is requested by the
      SNMP security level parameter.
          
      SSH supports a null cipher. The security considerations perhaps
      should explain that usage of the null cipher is generally not
      expected, even though implementations might support it for
      special cases (e.g. someone running ISMS over a secure IPsec
      tunnel or environments where encryption is illegal).

Security people were in the room when this was discussed and part of
the discussion was also that the SSHTM can blindly trust the SSH layer
without having to peek into the internals of the session state. Since
this meeting, we have worked under the assumption that the SSHTM can
trust the SSH layer to provide proper security. Unless there is a
major new argument, I would prefer to stick with this decision.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 04 Apr 2008 10:07:47 -0400

>       tunnel or environments where encryption is illegal).

SSH supports a "none" cipher, and imposes the following requirement:

   The "none" cipher is provided for debugging and SHOULD NOT be used
   except for that purpose.  Its cryptographic properties are
   sufficiently described in [RFC2410], which will show that its use
   does not meet the intent of this protocol.

I believe this is sufficient.  And in fact, the situations in which an SSH 
implementation might reasonably violate that SHOULD are likely to apply 
equally well to SNMP as to any other use.

> major new argument, I would prefer to stick with this decision.

I (still) think this is the right approach.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 04 Apr 2008 10:10:46 -0400

--On Thursday, April 03, 2008 06:02:19 PM -0400 "David B. Nelson" 
<[email-masked]> wrote:

> authentication mechanism, certificate chains, etc?

I don't think we think that.  I certainly don't.  And in practice, it can't 
provision those things, at least for SSH, because they are negotiated well 
before RADIUS gets involved.  The best an implementation could do is fail 
authentication if the already-established connection doesn't meet the 
requirements described by RADIUS, and really, if you're going to do that, 
the right solution is to configure the SSH server correctly in the first 
place so that it negotiates an acceptable connection.

While it might be useful to centralize management of configuration 
parameters such as which algorithms the SSH server is willing to support, 
RADIUS is not the right tool for doing so.

-- Jeff

---

From: "David Harrington" <[email-masked]>
Date: Fri, 4 Apr 2008 11:41:07 -0400

Hi,

I certainly have never argued that we should provision such things,
except the protocol. 

Question #1: I think the difference in security properties between
TLS, SSH, IPsec, and other "secure transports" are sufficiently large
that an operator might want the ability to say "I approve this service
as long as it is carried over SSH" rather than "I approve this service
as long as it is carried over ANY protocol that provides encryption
and integrity checking". The security considerations for these
protocols might identify environments in which the protocol is not
applicable because of some inherent design issue; for an operator
running an NM protocol in that environment, should they have the
ability to say "gee, my environment has that vulnerability, so I want
to ensure an applicable secure transport is used"?

Question #2: What exactly qualifies as a secure transport? I have
mentioned TLS, SSH, and IPsec even though these are at different
layers. If IEEE 802.1 provides a protocol for integrity checking and
encrypting at layer 2, should I consider that to be sufficient to meet
the integrity-and-confidentiality requirement for RADIUS, even if I
have no transport model prepared to deal with layer 2 protocol
security?

Question #3: In SNMPv3, we made the decision to not try to judge the
strength of security protocols, because it is a constantly moving and
subjective target. We chose instead to accept the
noAuthNopriv/authNoPriv/authPriv requirement and assertion approach.
The proposal to use RADIUS attributes for
integrity-and-confidentiality work roughly the same way. In the SNMPv3
case, we use the authPriv flags in the SNMPv3 message to say these
properties MUST be met; in the RADIUS case, the requirements are
specified in RADIUS attributes. If I understand correctly, in both
cases, it is up to the SNMP security model (now in concert with the
transport model) to ensure the requirements are met, and to assert to
the ACM system that such is the case, without telling the ACM which
protocols or ciphers or ... were used. Are the circumstances with
RADIUS sufficiently different that the require/assert model used for
Community amd USM is no longer adequate?

Question #4: In the Community and USM cases, the auth and priv
services were provided as part of the SNMP engine; now we are
proposing outsourcing those to "secure transports". In USM, it is up
to an operator to configure the user table to specify which auth and
priv protocols/mechanisms are acceptable; in the outsource model, the
operators may need to do that type of configuration in the SSH or TLS
or IPsec configuration. Is this acceptable?

Question #5: In the Community and USM security models, the user table
configuration specified acceptable protocols/mechanisms that are
suitable **for use with the SNMP engine**. In the TSM model, we migth
expect the operators to handle configuration outside SNMP. However,
those same protocols might be used for environments other than SNMP,
so the acceptable mechansisms for SSH general use might be different
than acceptable mechansisms for SSH for SNMP use. Is there really a
difference that operators would want to be able to specify different
requirements for the secure transport configuration, when used with
SNMP (or another NM protocol)?

dbh

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jeffrey Hutzelman
> Sent: Friday, April 04, 2008 10:11 AM
> To: David B. Nelson; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Isms] What granularity of attributes do we need 
> for the secure transport?
>

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 4 Apr 2008 10:50:00 -0400

Jeffrey Hutzelman writes...

> The best an implementation could do is fail authentication if the
> already-established connection doesn't meet the requirements described
> by RADIUS...

Yes, exactly.  The NAS checks to see that the already established [SSH]
connection meets the minimum security requirements provisioned in the RADIUS
Access-Accept message.  If that check fails, the NAS SHOULD behave as if an
Access-Reject message had been received.

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 4 Apr 2008 12:04:45 -0400

> I certainly have never argued that we should provision such 
> things, except the protocol.

I know that, but Bernard Aboba made such an argument in his review comments
of the -00 or -01 version of the RADEXT Management Authorization draft.   He
argued that once you can specify the transport protocol, you logically need
to specify various properties of the protocol.  The general consensus in
RADEXT was that we didn't want to go down that path.  As Jeff Hutzelman
pointed out in one of his recent posts, RADIUS is probably not the right
tool to be configuring all those security parameters of transport protocols.

My concern with re-introducing the Management-Transport-Protocol attribute
is that it brings baggage with it, including the need to address Bernard's
comments.

> to ensure an applicable secure transport is used"?

I think your point has validity.  Operators may well want to configure
different secure transport protocols, depending on the environment.  At this
moment, ISMS is only standardizing SSH for use with SNMP, but the general
problem space would include other protocols, and there are various security
properties of SSH that can be co0nfigured.

My question is whether this sort of configuration of the secure transport
protocol is something that needs to be checked by the NAS, using differing
criteria, on each and every user authentication?  I think that granularity
of configuration is generally handled by, well... configuration, and not
handled as part of user authorization.

> have no transport model prepared to deal with layer 2 protocol

There are really two questions here.  One is whether any given secure
transport (possibly including Layer 2) is sufficient to address the security
threat model of the particular deployment scenario.  The other is whether
there is a standardized SNMP Transport Model that allows the SNMP engine to
"know" that a secure transport is being used.

Right.

> integrity-and-confidentiality work roughly the same way.

Yes.

> In the SNMPv3 case, we use the authPriv flags in the SNMPv3 message
> to say these properties MUST be met; in the RADIUS case, the 
> requirements are specified in RADIUS attributes. If I understand 
> correctly, in both cases, it is up to the SNMP security model (now 
> in concert with the transport model) to ensure the requirements are
> met, and to assert to the ACM system that such is the case, without
> telling the ACM which protocols or ciphers or ... were used. 

I think that's right.

> Are the circumstances with RADIUS sufficiently different that the
> require/assert model used for Community and USM is no longer adequate?

I see no reason to believe so.
 
> or IPsec configuration. Is this acceptable?

Well, when you're outsourcing...

> suitable **for use with the SNMP engine**. In the TSM model, we might
> so the acceptable mechanisms for SSH general use might be different
> than acceptable mechanisms for SSH for SNMP use. Is there really a

That's a good question.  I would think that if SSH is used for other forms
of remote management (e.g. CLI) that what's "good for the goose is good for
the gander".  ;-)

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 4 Apr 2008 19:26:37 +0200

> I certainly have never argued that we should provision such things,

Speaking as technical contributor...

I think it is important to not confuse the configuration of say an
SNMP engine or an SSH implementation with RADIUS authentication /
authorization decisions. Certain things can very well be handled via
configuration.

/js

---

From: "David Harrington" <[email-masked]>
Date: Fri, 4 Apr 2008 13:40:27 -0400

Hi,

You are right. The wording I used was poor.

I do not believe we need to provision the security protocl; I think we
should allow an operator to decide which secure transport they want to
require as a conditon of granting access to the SNMP service. How that
secure transport is configured to deliver certain properties is out of
scope.

dbh

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Friday, April 04, 2008 1:27 PM
> To: David Harrington
> Cc: 'Jeffrey Hutzelman'; 'David B. Nelson'; [email-masked]
> for thesecure transport?
things,

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 4 Apr 2008 13:57:27 -0400

> I do not believe we need to provision the security protocol; ...

Meaning we don't need to specify such things as the selection of optional
modes, cipher suite, authentication mechanism, certificate chains, and so
forth.  Right? 

> I think we should allow an operator to decide which secure transport
> they want to require as a condition of granting access to the SNMP
> service.

Just the transport protocol name?  Or do you want to sub-specify versions,
e.g. SSHv2, TLSv1?  If you want to specify IPsec as one of these, do you
need to specify such things as IKEv2?

I think the devil is in the details.

If I understand your position correctly, to want to augment the existing
Management-Protocol-Protection attribute, which specifies the level of
security in an abstract fashion, with a reinstated
Management-Transport-Protocol attribute which names the mandated protocol
(and maybe the protocol version).  Right?  Do you anticipate that there
could be only one of these attributes in a RADIUS Access-Accept message, or
could there be more than one (i.e. acceptable alternatives)?

That seems to be a middle ground choice, between having only an abstract
assertion about the security level and having all the details and parameters
related to a secure transport protocol.

What do others think about this decision point?

-- Do we need only an abstract security level assertion?

-- Do we need the transport protocol name?

-- Do we need the transport protocol version?

-- Do we need any further details of security parameters?

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 4 Apr 2008 11:46:11 -0700

David Nelson spoke thusly:

"My question is whether this sort of configuration of the secure transport
protocol is something that needs to be checked by the NAS, using differing
criteria, on each and every user authentication?  I think that granularity
of configuration is generally handled by, well... configuration, and not
handled as part of user authorization."

With respect to IEEE 802.11 access, there are no RADIUS attributes that 
specify whether a given user is allowed to do WEP/WPA/WPA2.  It is 
assumed that security is negotiated between the AP and STA based on 
their configuration.  This seems to work OK, particularly
since separate SSIDs are typically provisioned for each supported security 
mechanism, so that user authorization can be handled based on the
SSID (provided in the Called-Station-Id).   

A similar approach might well work here -- we assume that the NAS is set 
up to allow/require various security mechanisms.  It might be useful for
the NAS to tell the RADIUS server what security mechanism has been
negotiated, and the RADIUS server might Accept/Reject the authentication
based on that information as well as the user-name.  But there is no
notion that the RADIUS server can exercise *control* over what is 
negotiated -- it is "here is what I'm doing, take it or leave it".

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 4 Apr 2008 20:46:41 +0200

> -- Do we need any further details of security parameters?

As technical contributor, I like the abstract security level
assertion. More granular control can be achieved by means of
configuration of the SNMP engine or secure transport protocol.

/js

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 08 Apr 2008 09:49:04 -0700

>>>>> "JS" == Juergen Schoenwaelder <[email-masked]> writes:

JS> Security people were in the room when this was discussed and part of
JS> the discussion was also that the SSHTM can blindly trust the SSH layer
JS> without having to peek into the internals of the session state. Since
JS> this meeting, we have worked under the assumption that the SSHTM can
JS> trust the SSH layer to provide proper security. Unless there is a
JS> major new argument, I would prefer to stick with this decision.

In particular, if you're going to outsource the complexity of security
to another protocol, which is being done by using SSH as a transport.
You either have to trust that transport to do the right thing or you are
going to fail to actually outsource much of the complexity in the first
place.  Plus if you strictly require only certain modes of the lower
transport then when it gets security upgrades (eg, new algorithms) you
won't because you too exactly specified requirements of it.

I think if the lower level says it can support authPriv you simply have
to trust it.  Doing anything else adds way too much complexity and layer
interaction that isn't needed.

-- 
Wes Hardaker
Sparta, Inc.

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 8 Apr 2008 11:15:24 -0600

Hi -

> From: "Wes Hardaker" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, April 08, 2008 10:49 AM
...
...

But it *also* means that the security administrator setting up an organization's
access control policy has to be able to trust that all the "authPrivs" used by
that lower layer within that organization are sufficiently strong for the information
that the access control policy allows to be carried.

If we don't say how that gets configured, then at least we need to make it
known as an operational security consideration.

Randy

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 08 Apr 2008 14:06:25 -0700

>>>>> "RP" == Randy Presuhn <[email-masked]> writes:

RP> But it *also* means that the security administrator setting up an
RP> organization's access control policy has to be able to trust that
RP> all the "authPrivs" used by that lower layer within that
RP> organization are sufficiently strong for the information that the
RP> access control policy allows to be carried.

RP> If we don't say how that gets configured, then at least we need to
RP> make it known as an operational security consideration.

Well, let me add the other half of my thoughts...

It comes back to (as always) required vs optional.  I do think it would
be beneficial to throw in 100 optional tags that can be used to supply
additional configuration for anything (transport security settings or
otherwise).  What I think would be wrong is if we required those to be
present or the transport couldn't be used.  Having them optional is fine
since they can be turned off when new features get deployed by SSH (or
whatever) that should be used instead.  I should have stated this
before...

Ideally I'd want a decoupling of the transport setup parameters as much
as possible with optional interfaces to be *able to* specify settings.
I'd also agree that if they're specified they have to be used (or the
transport can't be used if it's impossible...  discarding values in
security parameters because you don't understand or implement them is a
recipe for distaster).
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: "David Harrington" <[email-masked]>
Date: Tue, 8 Apr 2008 19:23:58 -0400

Hi,

Let's keep in mind where this thread started. This is NOT about
specifying all sorts of parameters for the security protocols and the
mechanisms that they use. 

This is about what RADIUS specifies as requirements to be met for the
service to be delivered by the NAS.

If I have the relationship between the NAS (RADIUS client) and the
RADIUS server correct, then the NAS asks the RADIUS server how the
service to be provided must be provisioned before providing that
service to the authenticated entity. In the case of the SSHTM, the
service we are looking to have authorized is an SSH subsystem over
which we want to run an SNMP session. It is specifically the SSHTM
that is asking whether an SSH subsystem is authorized for this user. I
don't know how we provide a "hint" that an SSH subsystem is what we
want, without having an attribute to specify that is the protocol we
are interested in running SNMP over. 

If we do not send a hint because there is no attribute for it, then is
it appropriate for RADIUS to **only be able to** respond that "any
transport protocol that provides integrity checking and encryption is
fine for SNMP for this user"? 

dbh

> Behalf Of Wes Hardaker
> Sent: Tuesday, April 08, 2008 5:06 PM
> To: Randy Presuhn
> Cc: [email-masked]
> forthe securetransport?

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 8 Apr 2008 21:37:39 -0600

Hi -

> To: "'Wes Hardaker'" <[email-masked]>; "'Randy Presuhn'" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, April 08, 2008 5:23 PM
> Subject: RE: [Isms] What granularity of attributes do we need forthe securetransport?
...
...

I think the corner we're painting ourselves into here is just as you
describe it, and that providing a way to configure the systems in
an administrative domain so that the actual security provided is
known and adequate, while a legitimate operational concern
which should be documented,  is probably also something that
the IETF won't ever get around to actually addressing.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 Apr 2008 15:34:15 +0200

> are interested in running SNMP over. 

I think this thinking is backwards. RADIUS is not a provisioning
protocol as far as I can tell.

Since the secure transport already exists when RADIUS comes into play,
all we can reasonably do is ship information about the actual secure
transport to the RADIUS server so that the RADIUS server can take this
into account when it takes a decision.

Radius experts, please correct me if I got this wrong.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 Apr 2008 15:39:28 +0200

On Tue, Apr 08, 2008 at 11:15:24AM -0600, Randy Presuhn wrote:
 
> But it *also* means that the security administrator setting up an
> organization's access control policy has to be able to trust that
> all the "authPrivs" used by that lower layer within that
> organization are sufficiently strong for the information that the
> access control policy allows to be carried.
>
> If we don't say how that gets configured, then at least we need to
> make it known as an operational security consideration.

Randy, can you check the text in <draft-ietf-isms-secshell-10.txt>?
There is already text talking about this - if you think the text needs
improvement, please post suggested changes.

/js

---

From: "David Harrington" <[email-masked]>
Date: Wed, 9 Apr 2008 10:56:57 -0400

Hi,

I want to make sure my choice of wording doesn't mislead.

When I say "the NAS asks the RADIUS server how the service to be
provided must be provisioned", I do NOT mean the RADIUS server
provides provisioning information or tells the NAS how to subsequently
provision the service.

The RADIUS server says to the NAS "if your configuration of the
service meets these requirements, then you can deliver the service to
this user; if your configuration does not meet these requirements,
then you MUST NOT deliver this service to this user".
--

I am trying to understand where the responsibilities lie, to see if
there is  enough information to make the determination. Let me lapse
in COPS-PR terminology, and think of RADIUS in terms of a policy
decision point (PDP) at the RADIUS server and a policy enforcement
point (PEP) at the NAS. So the RADIUS server must be configured to act
as the policy decision point, while the NAS must be configured to act
as the policy enforcement point. RADIUS only tells us the operators'
policy for the service for the authenticated user; the NAS enforces
the policy.

Operators have the responsibility to configure the RADIUS server to
specify the policy for "service to this user", and to configure the
security available on the NAS to enforce the policy. 

--
Let's first consider whether the NAS can enforce the RADIUS policy:

The SNMP transport/security models have the responsibility to
determine whether the transport meets the SNMP authPriv requirements.
If RADIUS sends an access-accept, then we know we have auth. If the
RADIUS policy says "integrity+confidentiality", the transport/security
model must check the transport to see if priv is provided. If it is
not, then we must treat this as an access-reject.

Actually, the SNMP engine doesn't check this; we trust that the
transport provides it if we request it in securityLevel for an
outgoing message, and for incoming we trust authPriv is provided if
tmStateReference says it is. But, we implicitly trust the transport
layer because SNMP has no capability to verify the requirement sent in
the  RADIUS policy (so in SSHTM we fill in tmStateReference with a
hard-coded value).

This raises the question of whether it is appropriate for us to design
a solution where RADIUS says "you MUST verify that the service meets
these requirements" and then gives us a requirement we know we cannot
check (because SNMP should not know any of the details of transport
security). So should RADIUS even send this transport-protection policy
to SNMP at runtime if we know SNMP cannot enforce this at runtime?

Realistically, we don't need this attribute in RADIUS if all NM
protocols will be expected to be similarly unable to *verify* how the
security has been configured, because they also should have no
knowledge of security configuration details. Right?

Consistency of security properties across management interfaces is
important to have holistic security. If other NM protocols, like the
CLI, are expected to be able to actually verify the security
configuration, then so should SNMP. And then it would make sense to
have the transport-protection RADIUS attribute. If RADIUS can require,
and other NM protocols can verify, other aspects of security
configuration, then SNMP should also be able to verify those details. 

If RADIUS will specify requirements for the service, we MUST be able
to verify we do meet the requirements.

dbh

> Sent: Wednesday, April 09, 2008 9:34 AM
> To: David Harrington
> Cc: 'Wes Hardaker'; 'Randy Presuhn'; [email-masked]
> forthesecuretransport?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 Apr 2008 17:18:06 +0200

> then you MUST NOT deliver this service to this user".

But would it not make sense in the SNMP case that the RADIUS client
says "I have user admin with auth/priv - shall I give her access?"
and the RADIUS server says either "yes" or "no"?

Do we need conditional yes answers, considering the fact that
transport properties likely can't be changed?

/js

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 9 Apr 2008 11:18:22 -0400

Juergen Schoenwaelder writes...

> protocol as far as I can tell.

RADIUS is not a host provisioning protocol, in the way that SNMP or DHCP
are, for example.  It is a service provisioning protocol.  That doesn't mean
that RADIUS provisions the static configuration of services, but it does
specify if and, to a limited extent, how a service is provided to a given
authenticated user at a given time.
 
> into account when it takes a decision.

Yes.  There are two ways in which the enforcement can occur.

If the NAS sends suitably descriptive "hint" attributes in the
Access-Request message, describing the service being requested, e.g. SNMP
over a secure SNNP Transport Model, or SNMP over SSH, the RADIUS server can
decide to send an Access-Reject if the user ought not to be provided with
that service, or the user cannot be provided that service using the
available transport.

Alternately, the RADIUS server can send an Access-Accept message specifying
the service the user is authorized to access and further conditions upon
that access, such as the security properties of the transport.  The NAS is
obligated to enforce these service provisioning restrictions, and if it
cannot, e.g. because the available transport fails to meet the security
restrictions, it will then treat the Access-Accept as if it had been an
Access-Reject.

Thus, the final "go/no-go" decision can reside either at the RADIUS server
or at the NAS, but in either case it is the RADIUS server that dictates the
conditions of providing the service.

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 9 Apr 2008 11:59:18 -0400

> to verify we do meet the requirements.

Yes.  It need not be done within the SNMP engine and, for the reasons you
have described, that's not a likely place for this enforcement to exist.  I
would think the likely place would be in the SSH server at the NAS.  It
could also exist in the RADIUS server, based on suitable "hint" attributes.
I think that is a user configuration choice, however, not a protocol design
choice.

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 9 Apr 2008 11:21:54 -0600

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> Sent: Wednesday, April 09, 2008 7:39 AM
> Subject: Re: [Isms] What granularity of attributes do we need for thesecuretransport?
...
...

You asked for it.

Existing text:
   The SSH Transport Model has no way to verify that server
   authentication was performed, to learn the host's public key in
   advance, or verify that the correct key is being used.  The SSH
   Transport Model simply trusts that these are properly configured by
   the implementer and deployer.

Add:
  Consequently, within a management domain using this transport
  model, steps outside the scope of this document MUST be taken
  to ensure that all systems within that domain have indeed been
  correctly implemented, deployed, and configured, and that those
  configurations cannot be modified in inappropriate ways.

That might be the intent of the following sections in the security
considerations section, but I must admit that they leave me with the
feeling of relying on "and then a miracle occurs", even with the level
of detail that's there.  Perhaps it's just the sheer number of assumptions.
But others in this thread have articulated those issues more clearly.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 11 Apr 2008 20:00:26 +0200

> But others in this thread have articulated those issues more clearly.

David,

can you massage something like Randy suggeste this into the security
considerations text?

/js