Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture

From: "Khanh Nguyen \(khanhvn\)" <[email-masked]>
Date: Thu, 21 Apr 2005 19:59:11 -0700

Sorry if I missed something, but when discussing about the keying
choices,
are we talking about (1) encryption keys or (2) authentication keys? 

If it's (1), I would vote for inband/encapsulation keying (I think
encaps 
is basically inband), and strongly oppose out-of-band.  Why need a whole

external, out-of-band infrastructure just to do something that can be
done 
easily by two Diffie-Hellman key exchange messages (like SSL/TLS has
been doing)

If it's (2), then maybe we first need to decide which 'abstract'
authentication method to be used, before going to the specific 
keying scheme implementation (some auth method may not need any 'key'):

+ kerberos authentication
+ public-key certificate (e.g. x509)
+ pre-shared key (PSK) auth
+ centralized AAA (e.g. radius)
+ password digest (user auth only)
+ host key files (SSH host auth)
+ etc...

Khanh

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ken Hornstein
> Sent: Thursday, April 21, 2005 1:18 PM
> To: [email-masked]
> Subject: [Isms] CALL FOR CONSENSUS: ISMS Architecture
> 
> ISMS members,
> 
> There's been a lot of discussion recently on the mailing list 
> about the pros and cons of different security models.  I 
> think the discussion has been good, but unfortunately I don't 
> think it's getting any closer to a consensus (I thank Robert 
> for trying to draw things closer; unfortunately Juergen and I 
> have been rather busy off-line, and I apologize for that).  I 
> know that some on the mailing list have expressed a 
> preference for choosing a security protocol first, but we've 
> been tasked with choosing the architecture first, and I 
> believe that is the appropriate approach.
> 
> Anyway, I'd like to call for a consensus on the security architecture.
> As we all know, the three choices are:
> 
> - Out of band keying (the architecture used by EUSM)
> - In-bakd keying (the architecture used by SBSM)
> - Encapsulation keying (the architecture used by TLSM)
> 
> What I would like to see is WG members express which 
> architecture(s) they prefer (you can choose more than one, 
> but please, don't choose all three).  Please feel free to 
> state your reasons for your choices, but in the interests of 
> reaching consensus in a reasonable timeframe, I am asking 
> that WG members please refrain from commenting on other 
> people's choices unless they feel that the person has stated 
> a fact which is obviously wrong.
> 
> Thanks for your time,
> 
> --Ken
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/isms
> 

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

---

From: Ken Hornstein <[email-masked]>
Date: Fri, 22 Apr 2005 15:03:49 -0400

>choices, are we talking about (1) encryption keys or (2) authentication keys? 

In general, we're talking about (1) encryption keys.  Actually, I don't
necessarily like to think about "keys" at this stage.  If we're doing
something like EK, then SNMP doesn't really know about keys at all.

>[...]

The issue is that most of the systems you list generally don't want
application protocols to know about their keys; they want applications
to treat the authentication exchange as a "black box".  When dealing
with different authentication schemes, the protocols I've seen that
handle this the best provide a framework that different authentication
schemes can plug into.  SASL is an example of this (I'm not saying it's
appropriate for SNMP, but it's an example of a good framework that
handles different authentication mechanisms).

--Ken