Subject: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd)

From: Ken Hornstein <[email-masked]>
Date: Fri, 04 Mar 2005 14:24:14 -0500

Greetings all.

Eric Fleischman had asked earlier on the mailing list how we (the WG
chairs) expected to achieve our milestones since we weren't close to
consensus on the proposals.  I said that we were having a teleconference
with our sheperding AD soon, and I wanted to wait until we had that
teleconference until I said more.

We had that teleconference today, and the results were surprising.  Sam
drafted the following note after the conference and has given me permission
to forward his note to the mailing list.  You can read his note below,
but I'll summarize now:

- EAP is not an appropriate protocol to use to authenticate SNMP, based
  on the EAP applicability statement (see sec 1.3 of RFC 3748).
- His recommendation is to re-consider the evaluation of the propsals
  based on this new information.
- The most productive route in his opinion is to consider solutions not
  based on EAP.
- The delay caused by this won't be held against the working group.

So .... where does that leave us?

I'd like to hear from WG members, but to me this means we might want to
restart the evaluation team process again.  This would mean that the
proposal authors would have another chance to change their proposals
significantly to address objections raised by the evaluation team.  But
we don't necessarily have to do the evaluation team process again (I
personally think it would be worthwhile to do the eval team process
again).

Anyway, I suspect it's going to be an interesting meeting in Minneapolis.
I apologize to all WG participants, but due to work committments I won't
be able to make it (I hope to participate via Jabber).

--Ken

Subject: Late Surprise: EAP is not appropriate for ISMS
From: Sam Hartman <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Fri, 04 Mar 2005 14:01:07 -0500

[Feel free to forward the following as appropriate.]

Hi, Ken and Juergen.  As we discussed on the phone today, I have run
across what I believe is a stumbling block for the current ISMS work.
I'm sorry that I did not notice this sooner; there has been a lot of
information to assimilate as I've joined the IESG.

It is my understanding that the ISMS review team recommended an
approach based on the EUSM proposal.  Part of this proposal depends on
being able to use EAP for authontication.

I'd like to draw your attention to the first part of the EAP
applicability statement in section 1.3 of RFC 3748:

     EAP was designed for use in network access authentication, where IP
        layer connectivity may not be available.  Use of EAP for other
           purposes, such as bulk data transport, is NOT RECOMMENDED.

ISMS is not a network access application.  the SNMP engines are not
authenticating in order to gain access to the network.  Instead ISMS
is authenticating network management traffic.  As such, it falls
outside the scope of the EAP applicability statement.

Multiple members of the IESG including myself would not like the see
the scope of EAP expanded beyond its intended applicability.  I have
also received concerns from the EAP community about desires to use EAP
beyond its intended scope.

One question probably running through your mind is why don't we want
EAP used as a general communications security/key exchange protocol.
I don't know that we have a consensus answer on that question but I'm
happy to share my personal answer.  First, EAP is kind of complex.  It
has a feature set that is necessary for its current use cases, but it
has a lot of complexity associated with the fact that it does not run
over IP and that it is intended to support proxying through AAA
servers.  That complexity is not generally necessary for
communications security.  Also, EAP did not start off providing many
security services; it started more as a message format for
multi-round-trip exchanges.  When appropriate, other protocols tend to
provide communications security without some of the costs of EAP.  In
addition, the IETF has a large number of communications security
protocols.  When protocols like EAP are developed for specific
purposes it is desirable to keep those protocols used for those
specific purposes.

What are these other protocols?  Well, general application security is
often accomplished with one or more of TLS, SASL, GSSAPI, or
soon DTLS.   In some cases, IPsec is an appropriate solution; I do not
believe ISMS is such a case.  It is my understanding that the netconf
working group, which is in a similar space to ISMS supports the ssh
protocol.  Ssh does provide a good framework for this sort of thing.
Kerberos is used by some people, although the Kerberos community would
generally prefer that you use their protocol via GSSAPI or SASL rather
than directly.  

I think the next step is to re-consider your evaluation of proposals
in terms of this new information.  Is EUSM still the best approach if
you give up the dependence on EAP?  What communications security
protocols should be used instead?

Considering solutions that do not depend on EAP is going to be more
productive than arguing that the EAP applicability statement should be
changed or that ISMS should be allowed to use EAP even though it falls
outside the applicability statement.  When you are done considering
solutions, noting what attributes you lose by not using EAP would be
useful.  Also, if any important attributes are lost by not depending
on EAP, please discuss those with me.

Finally, I'd like to apologize for the delay that this news may cause.
I realize that you were well on track to meet your March deadline.  I
also realize that any delay introduced by this message will be my
fault and will not be held against the working group.  Again, I'm
sorry that I did not realize this situation sooner.

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 4 Mar 2005 18:51:07 -0800

Hi -

> From: "Ken Hornstein" <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, March 04, 2005 11:24 AM
> Subject: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd)
...

I find it ironic that some of the reasons the AD gives for not wanting to
use EAP (complexity resulting from operating over non-reliable transport,
independence from IP, support for proxying, multi-step exchanges, etc.)
all contribute to the most complex aspects of the SBSM proposal.  If we
can't use EAP, are we doomed to re-invent it?

Randy

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 04 Mar 2005 20:26:13 -0800

>>>>> On Fri, 4 Mar 2005 18:51:07 -0800, "Randy Presuhn" <[email-masked]> said:

Randy> I find it ironic that some of the reasons the AD gives for not
Randy> wanting to use EAP (complexity resulting from operating over
Randy> non-reliable transport, independence from IP, support for
Randy> proxying, multi-step exchanges, etc.)  all contribute to the
Randy> most complex aspects of the SBSM proposal.  If we can't use
Randy> EAP, are we doomed to re-invent it?

I don't think you read the entire message.  He suggested multiple
alternatives.  SASL is another complex but already existing exchange
mechanism that has not been heavily discussed, but has in a few brief
messages before (see my design considerations message from 2 days ago
or so, or Ken Horstein's overview of SASL near the start of this
mailing list).  SASL is actually designed for application level
authentication agreement transactions, unlike EAP.

Choices going forward include:

SBSM:
  + the most flexible from a authentication acceptance, because it
    could be made to do anything we wanted.
  o We'd have to be careful about not throwing everything possible in
    and to limit feature creep (see my previous message on design
    considerations)
  + Offered the most security from a feature perspective.
  - It'd be a new security protocol.
  + Offers transfer of SNMP specific information (default contextEngineID)

  Auth mechanisms include: As desired.  Could include any of local
                           accounts, ssh [for auth not protocol],
                           X.509, AAA/radius, ...

SASL:
  + Uses an extensible authentication mechanism...
  - ...though some popular operator choices would likely never be
    usable (eg, ssh).
  + Could probably be shoe-horned into USM.
    (Could also be made to use other SM formats, such as SBSMRunning)
  - Though the one problem that EUSM had which was likely going to
    cause problems was the key selection criteria (was a combination
    of user name and IP addr).  This could likely be done by
    manipulating the user name field to select a key rather than a
    user.  I've been meaning to write about this for some time and
    hopefully I'll get to it soon.
  - Would require a fair amount of new study to make session keying
    work like it would need to.
  o would require new packets to transfer SASL messages within SNMPv3
    messages.  [this is neither positive nor negative.  Doing
    something in parallel like EAP did means a lot more inner-box
    complexity.  Something else I've been meaning to write about...]
  - Could result in many round trips to bring up a session (but other
    proposals already suffered from this as well).
  o It's unknown if the default contextEngineID could be "discovered".

  Auth mechanisms include: Many.  I'd have to look up the list again
                                  it's been too long since I read
                                  it. not ssh though.

TLSM:
  + uses pre-existing secure transports.
  - Transports would have to bubble up a user name and a fair amount
    of study would be required to make that happen in all needed cases.
  - only a few mechanisms exist, namely TLS and SSH which are both TCP
    based.  DTLS is "on the horizon" for UDP, but it likely eliminates
    any other transport types (ATM, ...)
  + SSH and TLS are popular with operators
  + Existing transports offer a lot of security (including
    anti-replay; the evaluation team left out discussion of the others
    that were previously discussed on the list and in the BOFs).
  - It's known that the default contextEngineID could not be
    "discovered".

  Auth mechanisms include: SSH, X.509, Accounts (and thus AAA/radius)

We could certainly cook up more, but those are likely the most likely
candidates.

-- 
Wes Hardaker
Sparta

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 04 Mar 2005 20:39:44 -0800

...
...
...

> We could certainly cook up more, but those are likely the most likely
IKE is conspicuously absent from this list. It strikes me as
the most obvious candidate if you want to have a separate
authentication/data transport strategy...

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 04 Mar 2005 20:45:06 -0800

I don't think I agree with all of your assessments below.

>     could be made to do anything we wanted.
As can SASL, IKEv2, and TLS/DTLS. It's simply a matter of adding
new mechanisms. Indeed, given that IKEv2, TLS, and SBSM all
use more or less the same DH-style framework, I don't think that
there's really any important difference here.

>   + Offered the most security from a feature perspective.
I don't see that this is the case. What security features 
do you believe that SBSM offers that IKEv2 and TLS don't offer.

>   - ...though some popular operator choices would likely never be
Why? 

...
>     any other transport types (ATM, ...)
DTLS works fine over any datagram transport. It's not bound to
UDP.

-Ekr

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 04 Mar 2005 20:50:31 -0800

>>>>> On Fri, 04 Mar 2005 20:39:44 -0800, Eric Rescorla <[email-masked]> said:

Eric> IKE is conspicuously absent from this list. It strikes me as
Eric> the most obvious candidate if you want to have a separate
Eric> authentication/data transport strategy...

I don't, so color me biased.  I'll explain that in a later message though.

-- 
Wes Hardaker
Sparta

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 04 Mar 2005 20:49:53 -0800

>>>>> On Fri, 04 Mar 2005 20:45:06 -0800, Eric Rescorla <[email-masked]> said:

>> could be made to do anything we wanted.

Eric> As can SASL, IKEv2, and TLS/DTLS. It's simply a matter of adding
Eric> new mechanisms. Indeed, given that IKEv2, TLS, and SBSM all
Eric> use more or less the same DH-style framework, I don't think that
Eric> there's really any important difference here.

Agreed to some extent.  Both SASL and EAP are extensible.  But to add
things to them means relying on a document likely to be produced in
another WG.  But you're right that we might be able to force that to
happen.

>> + Offered the most security from a feature perspective.

Eric> I don't see that this is the case. What security features 
Eric> do you believe that SBSM offers that IKEv2 and TLS don't offer.

I was assuming that the prevailing goal of many members of the WG
would be to force whatever the outcome of the authentication would be
into USM.  IE, whatever SASL was made to do would be to generate keys
for use via USM, where some of the other security features are then
lost (such as anti-replay).

>> - ...though some popular operator choices would likely never be

Eric> Why? 

I'm betting that there wouldn't be a strong desire to make that
happen.  Color me wrong if it happens.  I'd bet, however, that the
drive will be lost by that point.  I'd be very happy to be proven
wrong however.

-- 
Wes Hardaker
Sparta

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 04 Mar 2005 21:04:43 -0800

> I don't, so color me biased.  I'll explain that in a later message though.

Well, you may not think it's an obvious candidate, but I'd be
interested to hear an argument that puts it totally out of the
running...

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 04 Mar 2005 21:09:34 -0800

> another WG.  But you're right that we might be able to force that to

The reason why there's resistance to adding this sort of 
functionality is that it's technically tricky. It will
be equally technically tricky with SBSM. 

> lost (such as anti-replay).

But this isn't an argument for SBSM over e.g. TLSM, because TLSM
replaces USM and therefore *does* offer anti-replay. 

> drive will be lost by that point.  I'd be very happy to be proven

I'm very uncomfortable with the argument that we're in so much
of a hurry to avoid review by the WGs who are really tasked
to design this kind of flexible security protocol that 
we should instead design something wholly new.

-Ekr

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 04 Mar 2005 22:20:38 -0800

>>>>> On Fri, 04 Mar 2005 21:09:34 -0800, Eric Rescorla <[email-masked]> said:

Eric> But this isn't an argument for SBSM over e.g. TLSM, because TLSM
Eric> replaces USM and therefore *does* offer anti-replay. 

Never said otherwise.  Or didn't mean to.

Of the solutions, TLSM would be fine with me.  I've stated that many
times before.

-- 
Wes Hardaker
Sparta

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 04 Mar 2005 22:22:24 -0800

>>>>> On Fri, 04 Mar 2005 21:04:43 -0800, Eric Rescorla <[email-masked]> said:

Eric> Well, you may not think it's an obvious candidate, but I'd be
Eric> interested to hear an argument that puts it totally out of the
Eric> running...

I don't think anything is out of the running at this point.  That
includes IKE.  It wouldn't be my choice, but again I'll explain that
later.  I'll probably type it up Sunday on the plane...

One nice advantage that IKE has over the rest of the other options is
that it supports EAP!  [joke]

-- 
Wes Hardaker
Sparta

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 5 Mar 2005 08:56:51 +0100

> Choices going forward include:

IKE

...

The protocols that we actually use in production are TLS and SSH. We
use a fair amount of SASL as well, but typically layered on top of 
TLS (even if that is seen to be broken). I am living in a world where
people never have deployed USM and where people are likely to ignore
any solution which requires anything they are not familiar with. This
was the main reason to write TLSM - simply interface with what is out
there rather doing something new.

I do understand that other environments are different. I am just saying
that for us, only a solution reusing TLS or SSH is likely to be ever
considered and deployed.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: "Dondeti, Lakshminath" <[email-masked]>
Date: Sun, 06 Mar 2005 09:23:00 -0500

Hi Ken,

I am sorry I could not respond to this earlier, but I think this was 
discussed earlier, in January; Bernard Aboba wrote a number of options 
to this list on how to use EAP with due nod to the RFC 3748 
applicability statement.

regards,
Lakshminath

I can't find his emails in the ISMS archive:

++++++++++++=

There a number of ways that EAP could be used to secure SNMP, and they
have somewhat different implications:

a. EAP packets could be encapsulated within SNMP itself.
b. Keys derived from EAP could be used to secure SNMP.

Approach a) would appear to run afoul of the RFC 3748 Section
1.3 applicability statement:

"  EAP was designed for use in network access authentication, where IP
   layer connectivity may not be available.  Use of EAP for other
   purposes, such as bulk data transport, is NOT RECOMMENDED."

However, the applicability statement only applies to authentication
methods encapsulated within EAP; the same algorithms, if encapsulated
within SNMP itself, would not run afoul of the applicability statement.

It is also worth noting that the applicability statement does not apply to
RADIUS, so that RADIUS/EAP could be used between a RADIUS client and
server even if the protocol used to authenticate SNMP did not involve EAP.
As an example, there are IETF protocols that support CHAP authentication
(iSCSI is an example) and RADIUS is commonly used to centrally manage CHAP
authentication.

Approach b) is not in conflict with RFC 3748.  However, it would
introduce a link layer dependency into SNMP, since not all link layers
support EAP.  Typically link layer dependencies are to be discouraged,
since one of the goals of the TCP/IP protocol suite is to shield
applications from the link layer dependencies.

++++++++++++

Ken Hornstein wrote:

> ------------------------------------------------------------------------
>
> Subject:
> Late Surprise: EAP is not appropriate for ISMS
> From:
> To:
> [email-masked], [email-masked]
>
> To:
> [email-masked], [email-masked]
> CC:
> [email-masked], [email-masked], [email-masked], 
> [email-masked]
>
>
>------------------------------------------------------------------------
>

---

From: Ken Hornstein <[email-masked]>
Date: Mon, 07 Mar 2005 12:20:27 -0500

>to this list on how to use EAP with due nod to the RFC 3748 

I don't recall this email, but nevertheless ...

There seems to be a lot of concern at the IESG about using EAP for
things it wasn't intended to be used for (and I don't think that EAP
was ever intended to secure SNMP).  If the WG decides that it wants to
select EUSM and use EAP (EUSM may be an option if you don't use EAP), I
think we will be facing an uphill battle in the IESG.  I know what
Bernard said in the email you provided, but I got a very different
impression from Sam during our teleconference.

Additionally ... it seems in the new draft that the way you support
Kerberos is via EAP-TLS and "Kerberos cipher suites".  If by that you
are referring to RFC 2712 (this isn't in the references section), then
I think that is an issue, as that protocol is not well supported by TLS
implementations, is not really used in that many production
environments, and I personally don't think that it is reasonable to use
it as a way to specify Kerberos support for EUSM.  This is completely
seperate from exactly HOW you would use it, because even if it was
widely used and supported you're missing some pieces on how they hook
together.  Specifically ... if you're using TLS with Kerberos cipher
suites, exactly why do you need to use EAP at all?  Would EAP
implementations even know about the Kerberos cipher suite that was
negotiated by TLS?  Really, what you want is the Kerberos negotiation
to take place _within_ EAP, but AFAIK no such mechanism exists.
The same holds true for X.509 certificates; if you're expecting to
take certificates exchanged as part of TLS and use those to make
authorization decisions, I'm missing how EAP fits into that.

One other thought occurs to me.  I don't see how you negotiate between
doing EAP/TLS and PEAPv2/RADIUS (if I'm a manager that can do either,
how do I choose between the two when I talk to an agent?).

--Ken

---

From: Sam Hartman <[email-masked]>
Date: Sat, 05 Mar 2005 06:15:33 -0500

>>>>> "Randy" == Randy Presuhn <[email-masked]> writes:

    Randy> I find it ironic that some of the reasons the AD gives for
    Randy> not wanting to use EAP (complexity resulting from operating
    Randy> over non-reliable transport, independence from IP, support
    Randy> for proxying, multi-step exchanges, etc.)  all contribute
    Randy> to the most complex aspects of the SBSM proposal.  If we
    Randy> can't use EAP, are we doomed to re-invent it?

The irony is not lost on me.  I'd rather you not end up inventing your
own security protocol.  If you do end up rejecting all the security
protocols that it would be appropriate to use, I'd certainly
appreciate feedback to take to those protocol designers on why they
did not meet your needs.

Ending up with SBSM is not inherently wrong though.  IT may well be
that having two application-specific protocols (EAP for network
access, SBSM for network management) is better than trying to make one
protocol fit both applications.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Mon, 07 Mar 2005 17:10:57 -0500

>>>>> "Ken" == Ken Hornstein <[email-masked]> writes:

    >> I am sorry I could not respond to this earlier, but I think
    >> this was discussed earlier, in January; Bernard Aboba wrote a
    >> number of options to this list on how to use EAP with due nod
    >> to the RFC 3748 applicability statement.

    Ken> I don't recall this email, but nevertheless ...

    Ken> There seems to be a lot of concern at the IESG about using
    Ken> EAP for things it wasn't intended to be used for (and I don't
    Ken> think that EAP was ever intended to secure SNMP).  If the WG
    Ken> decides that it wants to select EUSM and use EAP (EUSM may be
    Ken> an option if you don't use EAP), I think we will be facing an
    Ken> uphill battle in the IESG.  I know what Bernard said in the
    Ken> email you provided, but I got a very different impression
    Ken> from Sam during our teleconference.

Hmm, I actually think what I'm saying is consistent with what Bernard
is saying.

When I pointed out to Bernard that using EAP tunneled within SNMP was
the goal, he agreed that fell outside the applicability statement.

---

From: Kaushik Narayan <[email-masked]>
Date: Tue, 08 Mar 2005 08:31:52 -0600

Hi Sam,

Please find my reply inline.

<snipped>

>the goal, he agreed that fell outside the applicability statement.

EUSM does not tunnel EAP within SNMP. EAP is used as defined over
  UDP or Layer 2 (as and when SNMP is used in a non-IP environment).
EAP is used to setup Keys between two hosts running SNMP engines
based on authentication via credentials such as X.509 certs, Kerberos,
shared secrets or passwords stored on a RADIUS server.

The SNMP engines running on these hosts then acquire these keys
to be used for securing SNMP via mechanisms as defined today in
SNMPv3. EUSM trying to fix the integration problem with least
amount change to both to SNMP and to existing security protocols,
this is important since churning the SNMP protocol by introducing
extensive new packet processing is going further increase the barrier
for use of SNMPv3.

I was want to point out the EUSM can work with EAP and RADIUS
without any change to either RADIUS or EAP.

regards,
   kaushik!

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 08 Mar 2005 10:28:05 -0500

>shared secrets or passwords stored on a RADIUS server.

Did you see my previous email on this subject?

Specifically, you seem to be relying on using Kerberos cipher suites
for TLS for the Kerberos authentication.  It's unclear to me how these
keys relate to EAP (in fact, I'm not even sure what the purpose is
of EAP in this mode).  The same is true for X.509.  This is completely
distinct from the fact that Kerberos cipher suites for TLS is notoriously
under-supported.

--Ken