Subject: RE: [NSIS] Req-Draft: Open Issue 5 Req 5.7.10 Hooks ...

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 8 Nov 2002 13:32:46 -0000

hi all,

I think it's right that, as an overall goal, we should aim to be able to have NSIS protocols hook into standardised security solutions developed already. Personally, I still think it should be a SHOULD requirement, to emphasise that a practical security solution implies more than just an objective set of security-specific requirements to be fulfilled.

There are three reasons:

*) as already pointed out (including, as referenced in another thread, steve bellovin's useipsec draft), rolling our own solution is going to be hard work and not necessarily leading to a good result;

*) the appropriate type of technique may be strongly dependent on where in the network and what signalling application we are talking about. Therefore, in any case, we should be looking to avoid hard coding any specific key management protocol into the framework or protocol design.

*) from a deployment perspective, we should be aware that administering the identities which are a key part of any key management solution is not a zero cost activity. So, having the ability to re-use existing key management protocols at least opens the door to re-using identity administration which is already being done. Else it's much more likely that people just won't bother at all.

There's actually a lot of potential components "out there", certainly more of them (and more widely available) than 5 years ago - even leaving aside PKIs (sometimes useful), there is a whole AAA capability for users including roaming ones, and more recently activities in places like send w.g. and rpsec. We should be looking to be able to exploit all that.

cheers,

robert h.

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: 06 November 2002 10:37
> To: [email-masked]
> Subject: [NSIS] Req-Draft: Open Issue 5 Req 5.7.10 Hooks ...
> 
> 
> hi
> 
> marcus raised the question what todo with this paragraph. 
> there are the
> following options:
> 
> a) drop it (without replacement)
> b) replace it by something more concise
> c) move it to the framework
> 
> i would like to get an idea what people think about the 
> possible interaction
> between nsis and key management protocols. i personally think that key
> management is an important topic and should be addressed in 
> the requirements
> somehow.
> 
> ciao
> hannes
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of
> > Hannes Tschofenig
> > Sent: Monday, November 04, 2002 6:12 PM
> > To: [email-masked]; [email-masked]
> > Subject: RE: [NSIS] Req-Draft: Open Issue 5 Req 5.7.10 Hooks ...
> >
> >
> > hi marcus
> >
> > i think that nsis should be able to interact with other 
> protocols (called
> > hooks in this context). other protocols also require such 
> interaction. to
> > make sure that the interaction is actually possible (and 
> that it works in
> > the expected way) a requirement should be specified. is the 
> descripion too
> > fuzzy? should it simply be discussed in the framework only?
> >
> > ciao
> > hannes
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]On Behalf Of
> > > Marcus Brunner
> > > Sent: Friday, November 01, 2002 11:37 PM
> > > To: [email-masked]
> > > Subject: [NSIS] Req-Draft: Open Issue 5 Req 5.7.10 Hooks ...
> > >
> > >
> > > Req-Draft: Open Issue 5 Req 5.7.10 Hooks ...
> > > --------------------------------------------
> > >
> > > Proposal to remove req 5.7.10 " Hooks with Authentication and Key
> > > Agreement
> > > protocols"
> > >
> > > 5.7.10 Hooks with Authentication and Key Agreement protocols
> > >
> > > This requirement covers two subsequent steps before a signaling
> > > protocol is
> > > executed and the required hooks. First there is a need to 
> agree on a
> > > specific authentication protocol. Later this protocol is 
> executed and
> > > provides authentication and establishes the desired security
> > > associations.
> > > Using these security associations it is then possible to
> > exchange secured
> > > signaling messages.
> > >
> > > The signaling protocol implementation SHOULD provide hooks to
> > > interact with
> > > protocols that allow the negotiation of authentication 
> and key agreement
> > > protocols. Although the negotiation of an authentication and key
> > > management
> > > protocol within the signaling protocol may be outside the scope
> > > it is still
> > > required to trigger this exchange in case that no such security
> > > association
> > > is available.
> > > This requirement originates from the fact that more than one key
> > > management
> > > protocol may be used to provide a security association 
> for the signaling
> > > protocol. Hence the communicating entities must be 
> capable to agree on a
> > > specific authentication. The selected authentication and 
> key agreement
> > > protocol must however be able to create a security association
> > > that can be
> > > used within the signaling protocol.
> > >
> > > Key management protocols typically require a larger number of
> > messages to
> > > be transmitted to allow a session key and the 
> corresponding security
> > > association to be derived. To avoid the complex issue of embedding
> > > individual authentication and key agreement protocols 
> into a specific
> > > signaling protocol it is required that most of these protocols
> > > are executed
> > > independently (prior to the signaling protocol) and 
> although the key
> > > management protocol may be independent there must be a way for the
> > > signaling protocol to access and use available (i.e. already
> > established)
> > > security associations to avoid executing a separate key
> > > management protocol
> > > (or instance of the same protocol) for protocols that 
> closely operate
> > > together. If no such security association exists then there
> > > SHOULD be means
> > > for the signaling protocol to dynamically trigger such a protocol.
> > >
> > >
> > >
> > >
> > > --------------------------------------
> > > Dr. Marcus Brunner
> > > Network Laboratories
> > > NEC Europe Ltd.
> > >
> > > E-Mail: [email-masked]
> > > WWW:    http://www.ccrle.nec.de/
> > > Phone: +49 (0) 6221 905 11 29
> > > personal home page: http://www.brubers.org/marcus
> > >
> > >
> > > _______________________________________________
> > > nsis mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/nsis
> >
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> >
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis