Subject: [Isms] Limited time to charter

From: Sam Hartman <[email-masked]>
Date: Thu, 11 Aug 2005 15:58:57 -0400

Hi, folks.

I'd like to draw your attention to our remaining milestone:

   Aug 05    Working group will recharter to include publication goals
      or shutdown if no consensus on a technical direction is reached by
         this time

August is fast passing us by and we don't have much time.

I'd like to recommend to the chairs that they consider tools available
for increasing the speed of our discussion.  In particular it may be
appropriate to set up conference calls, IM sessions or other more
realtime communications channels to work through issues.

I know there had been some discussion of an interim meeting.  So far,
I don't see that an interim meeting is all that likely to resolve the
types of concerns currently being discussed and so I am reluctant to
approve such a meeting.  I will however consider proposals for such a
meeting particularly if people can explain what we could accomplish
with an interim that we are not accomplishing on the list.  I will
probably not be able to attend the meeting myself because of limited
travel funding but could participate by phone.

Keep in mind that interim meetings must be approved 30 days in advance
and that both Bert and I believe dragging things out past September is
unacceptable.  

While I remain optimistic that we can come to consensus, I must now
entertain the very real possibility that we will fail to come to
consensus.  Please consider this message the formal consultation
required prior to termination of a working group under section 4 of
RFC 2418.  At this time it is my opinion that absent an interim meeting
we must choose a technical direction by the close of August.  If that
does not happen this working group will close.  I will consider
changes in this time table but currently do not see circumstances
under which I'm likely to agree to such a change.

Sam Hartman
IETF Security Area Director

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

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 12 Aug 2005 00:18:33 +0200

[Sam, do you want us to keep teh CC: line to all those
 lists at mit.edu?]

Dbh and others,
W.r.t.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On
> Behalf Of David B Harrington
> Sent: Thursday, August 11, 2005 23:33
> To: 'Sam Hartman'; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [Isms] Limited time to charter
> 
> 
> Hi,
> 
> As stated in another message, I think that discussing SSH vs RADIUS vs
> PKI vs local accounts is thinking too much about the protocols, and
> not enough about the high-level problem of leveraging security
> infrastructure in complete network management **systems**.
> 

I would like to point out that in the grand scheme of things, many
operators and enterprises use SNMP only in the Element to Element
Management Layer (ELM) and use totally different technologies to 
communicate between ELM and NML and upt to SML and up to BML
(Network Management Layer, Service Management Layer and Business 
Management Layer), i.e. the TMN piramid. They use terms like
southbound (from EML to EM) where they use SNMP and northbound
(from EML to NML and up) where they often use Corba etc etc.

I do not believe that we have the correct participants to try and
address the security infrastructure for that complete NM system
picture. YMMV.

Bert

---

From: "Nelson, David" <[email-masked]>
Date: Fri, 12 Aug 2005 11:51:55 -0400

Sam Hartman writes...

> In particular, I think the minimum set of documents you would need is:
> 
> * Mapping describing how ssh is used between the two snmp engines
> 
> * Mapping describing what radius attributes are used to populate
>   securityname and other SNMP parameters
> 
> * Document describing the ssh security model; probably this can be
>   folded in as part of the first document.  This document allows for
>   the securityname to be mapped and points to the radius document as
>   an example of how one does it in a radius environment.  Discusses
>   mapping to level; if ssh is used as it traditionally is used,
>   everything maps to authpriv.  Otherwise specify level in terms of
>   the over the wire ssh behavior.
> 
> * An applicability statement that sets up reasonable mandatory to
>   implement methods.  You'll probably want to require radius support
>   although of course that is a WG decision.

That sounds like the correct list of documents, to me.

---

From: "Nelson, David" <[email-masked]>
Date: Fri, 12 Aug 2005 15:13:00 -0400

David B Harrington writes...

> Could we use this capability to provide a user-to-group mapping? Or do
> various accounting/business models differ too much from an SNMP access
> control model to make reuse of this field problematic?

RADIUS allows a modified User-Name attribute to appear in an
Access-Accept message, so that the identity used in subsequent
accounting requests can be tailored in certain application environments.
Note that this can cause problems with the "source routing" properties
of an NAI contained in User-Name, when used in RADIUS Proxy
environments, so a new RADIUS attribute is being standardized in the
RADEXT WG, called Chargeable-User-Identity, that may supplant the
practice of sending a modified User-Name in an Access-Accept. 

> Do we want to support PAP and CHAP and MSCHAPv2? I see CHAP would be
> useful for a command-line SNMP application, but what about something
> like HPOV where there isn't necessarily a human sitting at the
> management application when a scheduled poll occurs?

Any of these RADIUS authentication methods can [ultimately] use "static"
usernames and passwords.  If a management station is acting
autonomously, it can inherit the credentials of a human entity, or it
can be issued its own credentials as an application entity.

> Do we need to store the credentials at the management application to
> handle scheduled non-human polling, ...

For PAP, CHAP and MSCHAPv2, the answer is yes.

> ... and do we then need to worry about
> key distribution to various applications 

There will be a requirement to provision the applications with the
authentication credentials.  The encryption keys for the sessions (e.g.
SSH) would not need to be statically provisioned (at least I do not
believe so).

> ... (not to mention the
> possibility of somebody finding the credentials in the application
> datastore)?

That is a risk, of course.  I think it is a risk whenever a non-human
entity is being authenticated, unless the credentials are somehow
encapsulated in tamper resistant hardware implementations.

---

From: "Salowey, Joe" <[email-masked]>
Date: Fri, 12 Aug 2005 14:48:52 -0700

> From: David B Harrington [mailto:[email-masked]] 
> Sent: Friday, August 12, 2005 11:48 AM
> To: Narayan, Kaushik
> Cc: 'Sam Hartman'; [email-masked]
> Is there a document already in existence that describes how 
> to use RADIUS for SSH user authentication? 
> 

[Joe] No and its not clear that you would want one.  SSH supports a
number of authentication methods.  The easiest to integrate with RADIUS
is the username/password method which sends a clear text password.  This
can be used in RADIUS PAP, CHAP or MS-CHAP authentication.  This mode of
operation may have undesirable security properties since the password is
available in cleartext to the SSH intermediaries. Other SSH user
authentication methods do not have RADIUS support at this point, but it
not clear that you would really want to support these in RADIUS (support
could potentially be added by a GSS-API to EAP bridge mechanism, but
that is probably beyond the scope of this group). 

> Or do we need to write one to document how to get the 
> securityName information from RADIUS into SNMP? 
>
[Joe] This would probably be a good idea.  The definition of which
attribute to use would be necessary.  Perhaps the username attribute
could be used in the access accept.  
 
> Do we need to go read the username from the 
> SSH_MSG_USERAUTH_REQUEST to populate securityname? Do 
> pretty-standard clients mirror the User-Name Attribute from 
> the RADIUS Access-Request in the SSH_MSG_USERAUTH_REQUEST?
> 
> Or do we need to go directly read the User-Name Attribute 
> from the RADIUS Access-Request packet, because 
> pretty-standard clients do not always mirror this? 
> 
> OR do we need to go directly read the User-Name Attribute 
> from the RADIUS Access-Accept packet, since this MAY be 
> different than the User-Name Attribute in the RADIUS 
> Access-Request packet? According to RFC2865, we SHOULD use 
> this if we were doing subsequent accounting request packets. 
> 

[Joe] I would think it would be best to use the user name (or some other
attribute) in the access-accept since this has actually been validated
by the RADIUS server. 

> Could we use this capability to provide a user-to-group 
> mapping? Or do various accounting/business models differ too 
> much from an SNMP access control model to make reuse of this 
> field problematic?

[Joe] It would seem that the use of SNMP is a separate matter.  There
are business and accounting models which require certain protection of
the actual username so addition attributes have been proposed for
carrying identity for charging users.  Right now I don't think this
would interact with SNMP uses. 

> 
> The format of the username MAY be one of several forms:
> 
>       text      Consisting only of UTF-8 encoded 10646 [7] characters.
> 
>       network access identifier
>                 A Network Access Identifier as described in RFC 2486
>                 [8].
> 
>       distinguished name
>                 A name in ASN.1 form used in Public Key authentication
>                 systems.
> 
> Do we need to document the acceptable choices for use with SNMP?
> 

[Joe} Some guidance on naming is necessary. 

> Do we want to support PAP and CHAP and MSCHAPv2? I see CHAP 
> would be useful for a command-line SNMP application, but what 
> about something like HPOV where there isn't necessarily a 
> human sitting at the management application when a scheduled 
> poll occurs? 
> 

[Joe] Note that these are only supported in RADIUS and not in SSH. So
they are not really usable except as a back end mechanism that takes a
cleartext password as input from the client. 

> Do we need to store the credentials at the management 
> application to handle scheduled non-human polling, and do we 
> then need to worry about key distribution to various 
> applications (not to mention the possibility of somebody 
> finding the credentials in the application datastore)? Are 
> there pretty standard client approaches for this, for, say, 
> scheduling CLI script retrieval of device configurations? How 
> are these issues dealt with? Are these solutions documented somewhere?
> 
> David Harrington
> [email-masked]
> 
> > From: Kaushik Narayan [mailto:[email-masked]]
> > Sent: Friday, August 12, 2005 1:50 PM
> > To: [email-masked]
> > Cc: 'Sam Hartman'; [email-masked]
> > Hi David,
> > Please find my reply inline
> > 
> > <snipped>
> > 
> > 
> > > >
> > >Is the RADIUS user authentication different from the SSH user 
> > >authentication?
> > >
> > >It appears to me that in the SNMP-to-SSH mapping, securityName can
> be
> > >obtained from the user name contained in the
> SSH_MSG_USERAUTH_REQUEST
> > >message. This works for publickey, password, and host-based 
> > >approaches.
> > >
> > >I don't see any mention of RADIUS in the "SSH Authentication
> > Protocol"
> > >draft. If RADIUS is used to provide the SSH authentication, how do
> we
> > >get the username from RADIUS to pass via the
> SSH_MSG_USERAUTH_REQUEST
> > >into the SNMP engine? Or do we go directly to RADIUS to get the 
> > >username, and if so does that also work for other backend 
> > >authentication metyhods, such as publickey, password, and
> host-based
> > >or would every authentication method require its own user-mapping 
> > >technique? Is there a document already in existence that
> > describes how
> > >to use RADIUS for SSH user authentication?
> > >
> > 
> > 
> > 
> > Most SSH implementations support user/password based authentication 
> > with a RADIUS server and support RADIUS PAP/CHAP/MSCHAPv2.
> > This is pretty
> > standard RADIUS client behavior.
> > 
> > regards,
> >    kaushik!
> > 
> > 
> > 
> 
> 
>

---

From: "Nelson, David" <[email-masked]>
Date: Fri, 12 Aug 2005 17:51:35 -0400

Kaushik Narayan writes...

> I am not aware of the PAM API supporting passing of
> module specific parameters.

So I thought.  This isn't a show-stopper, of course.  It just means that
some API enhancements would be required in the PAM module for {RADIUS,
TACACS+, etc}. This would not affect any on-the-wire protocol.