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

From: Wes Hardaker <[email-masked]>
Date: Thu, 21 Apr 2005 19:48:00 -0700

>>>>> On Thu, 21 Apr 2005 22:38:05 -0400, "David B Harrington" <[email-masked]> said:

David> If me, and the suggestion was how to characterize "maybe", does
David> that mean you consider Encapsulation keying sub-optimal? I just
David> want to be sure I understand your comment.

Yes, but since I can't qualify as "slightly" then I'd have to say yes
because it doesn't offer as much compatibility.

-- 
Wes Hardaker
Sparta, Inc.

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

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Fri, 22 Apr 2005 00:30:59 -0400

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

To ask this question correctly, it should sound "are we talking about
short-term keys, or long-term keys to authenticate the exchange/creation
of the short-time keys?"

> just to do something that can be done easily by two Diffie-Hellman key
exchange
> messages (like SSL/TLS has been doing)

You're very generous with computing resources. Even TLS (usually)
doesn't do DH key exchange.

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

Very nice - except that the contestants are about equally divided
between these: some need Kerberos, some need PKI, some insist that
*their* "constituency" can deal efficiently only with SSH. And it's not
a big deal to make a code stew to support all of the above and below -
except that it's next to impossible to analyse security property of the
resulting stew. Not that everybody cares, of course...

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

---

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

Pls see line...

> From: Blumenthal, Uri [mailto:[email-masked]] 
> Sent: Thursday, April 21, 2005 9:31 PM
> To: Khanh Nguyen (khanhvn); Ken Hornstein; [email-masked]
> Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture
> 
> To ask this question correctly, it should sound "are we 
> talking about short-term keys, or long-term keys to 
> authenticate the exchange/creation of the short-time keys?"

I am not sure what you mean short/long-term keys, but from the 
abstract/architectural point of view, securing a communication 
system generally has two orthogonal domains: (1) encryption +
data integrity and (2) authentication.  The former domain (1) 
is about communicated data (bits and bytes), while the later (2) 
is about communicating entities (users/snmp managers/snmp agents).  
In this architectural discussion, I think it's useful to recognize 
the differences b/w these two domains.

> 
> > just to do something that can be done easily by two 
> > Diffie-Hellman key exchange
> You're very generous with computing resources. 

DH requires an integer exponential and a modulo operation per 
session.  So I think it's not that computing intensive.  HTTPS
commodity servers now a day can easily handle millions of sessions 
per day.  Most SNMP agents have much less than that, so I don't
think this is an issue at all.

>Even TLS (usually) doesn't do DH key exchange.

I mean DH key ex, not DH certificate (which is for auth).  
SSL/TLS suites have two options for key exchange: DH and RSA.  
I am not sure which one is used more frequently, but some sources 
say DH is more secure. 

http://www.scramdisk.clara.net/pgpfaq.html#SubRSADH 

Anyway, I cited DH as an example, but RSA key exchange can be used too.

I don't think they are much different in term of computing resource.

> > authentication method to be used, before going to the 
> specific keying 
> > scheme implementation (some auth method may not need any
> 'key'):
> 
> Very nice - except that the contestants are about equally 
> divided between these: some need Kerberos, some need PKI, 
> some insist that
> *their* "constituency" can deal efficiently only with SSH. 
> And it's not a big deal to make a code stew to support all of 
> the above and below - except that it's next to impossible to 
> analyse security property of the resulting stew. Not that 
> everybody cares, of course...

That's why I proposed a single authentication method independent
with underlying transport (connectionless, TCP, TLS):  The
Localized PSK (LPSK) method.  I borrow your idea (USM localized 
Keys) and extend it in conjuction w/ a PSK method such as SRP
to auth snmp entities (I mean at session/connection level, not MAC)

Best Regards.

Khanh

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

---

From: "Khanh Nguyen \(khanhvn\)" <[email-masked]>
Date: Fri, 22 Apr 2005 14:28:23 -0700

> From: Ken Hornstein
> 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.

I completely agree.  As Kausick earlier pointed out, the primary
issue that need to be decided first is whether to do the 
security services at (a) transport layer or (b) application 
(SNMP) layer.  Another primary issue is what type(s) of transport 
to use: sessionless (e.g. USM), session-oriented (e.g. EUSM/SBSM) 
or connection-oriented (e.g. TLSM).  Once we can agree on these 
issues, it'll be easier to talk about keying mechanism.
W/out a common base, the discussion could be very confusing.

Khanh

---

From: "Fleischman, Eric" <[email-masked]>
Date: Wed, 27 Apr 2005 08:52:32 -0700

My view:
OOB -- Depends on specific approach but isn't attractive in the general
case  
IB  -- yes, my preference
EK  -- Depends on approach

--Eric

> [mailto:[email-masked]] On Behalf Of Juergen Quittek
> Sent: Tuesday, April 26, 2005 5:22 PM
> To: [email-masked]
> Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture
> 
> Dear all,
> 
> We have to come to an agreement on the architecture we will use. Ken 
> asked some days ago, but only one of the replies stated a clear 
> position.
> 
> Shall I take this as an indicator that the rest is not decided yet? Or

> does not care?  Or can we go on with the table that Robert
posted?
> 
> >
> > Keying|      For             | Against | Abstain
> > ------+----------------------+---------+-------------
> > OOB   |  6 (4 Yes, 2 Maybes) |  3 No   | 4 no comment
> > IB    |  8 (6 Yes, 2 Maybe)  |  1 No   | 4 no comment
> > EK    | 10 (5 Yes, 5 Maybe)  |  0 No   | 3 no comment
> >
> >
> > Key:  Y=YES/preference    (y=second pref/implied pref)
> >       M=MAYBE/second pref (m=implied second pref)
> >       N=NO
> >       -=no explicit rejection (no comment)
> >
> > OOB | IB  | EK  | Name (alphabetical by first name)
> > ----+-----+-----+----------------------------------
> >  N  |  N  |  Y  | David Harrington
> >  -  |  y  |  -  | David Perkins
> >  N  |  Y  |  M  | Ira McDonald
> >  M  |  -  |  Y  | Juergen Schoenwaelder
> >  Y  |  M  |  -  | Kaushik Narayan
> >  Y  |  -  |  -  | Marcus Leech
> >  Y  |  -  |  M  | Martin Soukup
> >  N  |  Y  |  M  | Robert Story
> >  m  |  y  |  Y  | Sam Hartman
> >  Y  |  -  |  m  | Sharon Chisolm
> >  -  |  M  |  Y  | Tom Petch
> >  -  |  Y  |  Y  | Uri Blumenthal
> >  -  |  Y  |  M  | Wes Hardaker
> >
> 
> Has anybody changed her/his mind?
> Or does anybody want to replace a dash by a letter?
> 
> Thanks,
> 
>     Juergen
> -- 
> Juergen Quittek        [email-masked]       Tel: +49 
> 6221 90511-15
> NEC Europe Ltd.,       Network Laboratories        Fax: +49 
> 6221 90511-55
> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   
> http://www.netlab.nec.de
> 
> 
> 
> --On 4/21/2005 4:17 PM -0400 Ken Hornstein wrote:
> 
> > 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 
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.
> > [email-masked] https://www1.ietf.org/mailman/listinfo/isms
> 
> 
> 
> [email-masked] https://www1.ietf.org/mailman/listinfo/isms
>

---

From: "Martin Soukup" <[email-masked]>
Date: Wed, 27 Apr 2005 21:27:27 -0400

Update my row please:

OOBK - yes
IBK - no
EK - no

Martin.

> [mailto:[email-masked]] On Behalf Of Fleischman, Eric
> Sent: April 27, 2005 11:53 AM
> To: Juergen Quittek; [email-masked]
> OOB -- Depends on specific approach but isn't attractive in 
> the general case  
> IB  -- yes, my preference