Re: [Call-home] draft now posted; BoF?

HI Eliot,

The key issue, which I have said in previous email on the ISMS list,
and you have touched on below, is what credentials are being
used by each end of the connection, followed by what autorization
rules are in being used and where they are applied.

I didn't feel like you answered my previous question about
this on the ISMS list. That is, you did provide a response,
but I could not understand it.

Once it is clear what credentials are available, then the
next step is to show the mechanisms that would be used to
verify the identities.

On Tue, 27 Sep 2005, Eliot Lear wrote:
> Juergen Schoenwaelder wrote:
> > On Mon, Sep 26, 2005 at 03:46:29PM +0200, Eliot Lear wrote:
> >  
> > 
> >>A draft is now posted - draft-lear-callhome-description-00.txt.  It
> >>doesn't yet have much in the way of SNMP specifics but I am working on
> >>that now.
> > 
> > 
> > I am not sure what the scope of your efforts here are. Do you limit
> > this in scope to the management domain (which is somewhat implied by
> > talking about managers and agents) or do you want to address the more
> > general question of how to reverse connection establishment from the
> > inside to the outside. 
> 
> I've been asked to consider the broader architectural issues (if any),
> but my interest is in network management as well.  It would be good if
> someone could flag issues they see as broader than the area of
> management if I miss them.
> 
> > In any case, I would like to discuss this issue
> > not only in the context of SNMP, but at least also consider netconf,
> > where the required to implement transport mapping also does not
> > provide call home at the moment.
> > 
> > Personally, I am concerned about the security considerations. I would
> > very much prefer a solution where the authenticated identities and the
> > way they are authenticated remain the same, regardless whether I am
> > using call-home or not. Now, it may turn out that this is not feasible
> > to achieve. If that is the case, these findings need to be documented
> > somewhere.
> 
> I am not sure this is a problem with the notion call home, but perhaps
> with mechanisms used to achieve it.  For instance, BEEP today supports
> either side initiating a connection as well as mutual authentication via
> TLS.  In the case of SNMP, therefore, there would be a mapping from
> securityName to X.509 subject (amongst other things), either directly or
> via SASL EXTERNAL.
> 
> But I wonder whether we should mandate such a requirement.  Also if we
> are making use of substrates such as SSH, BEEP, or for that matter HTTP,
> how we structure those interfaces.
> 
> In a practical sense, a service provider already provides a username and
> password to an end user.  It would seem impractical for the user to
> provide a username and password back to the service provider when an
> X.509 certificate would do the job.
> 
> > 
> > 
> >>Did I miss architectural issues in the draft?
> > 
> > 
> > I only had a very quick read. For me, the really interesting issue is
> > to figure out how much security protocols like SSH or TLS actually
> > [rely] on the connection initiation procedure or whether the
> > client/server roles can be "turned" before the security protocols do
> > their work. In other words, I would like to know whether some
> > extensions to say SSH can solve most of the issues with call home
> > support in ISMS and NETCONF.
> 
> I'm not quite sure what you're asking for.  Are you suggesting, for
> instance, that the initiator have a host key and the listener make use
> of a user key?
> 
> Eliot
> 

Regards,
/david t. perkins

_______________________________________________
Call-home mailing list
Call-home@ietf.org
https://www1.ietf.org/mailman/listinfo/call-home