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

From: "Blumenthal, Uri" <[email-masked]>
Date: Sat, 5 Mar 2005 00:17:26 -0500

>> Choices going forward include:
>>
>> SBSM:
>>...
>> SASL:
>>...
>> TLSM:
>>...
>>
>> We could certainly cook up more, but those are likely the most likely
>> candidates.
>
> 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...

IMHO, separation of authentication and data traffic protection
is a-must.

IKE is a well-analyzed Key Exchange protocol, whose entire job is to
just authenticate end-points, agree on SA parameters and generate keys
(not encumbered by other functionality).

I would strongly object to re-inventing key exchange protocol. I'd
strongly support a minimal explicit interface to something like IKE.
I want to emphasize, that even INTEGRATING an EXISTING GOOD Key 
Exchange protocol is non-trivial and tricky enough.

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

I'd say it's the most convenient way. USM does well traffic integrity 
and confidentiality. Replay protection is weaker - but it was a
conscious
decision based on inability to find reliable clocks and desire to avoid
complicated and expensive re-synchronization, coupled with the nature
of SNMP traffic (not a true "session" with good data flow, etc). I
question, whether the reasons that prevented us from incorporating
a better anti-replay into USM, still stand and will bug other
models.

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

I'd be more interested to see an IKE-based mechanism to establish
dynamic session 
and feed it to USM, than to create an entirely new security model and
spend 
unpredictable time analyzing it. But again, SNMP architecture allows 
for many security models - there's room for whatever you may need, 
just design it and pay the vendors to code and offer it.

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

---

From: Ken Hornstein <[email-masked]>
Date: Mon, 07 Mar 2005 14:32:29 -0500

>Exchange protocol is non-trivial and tricky enough.

I definately agree that IKE is well-analyzed (maybe not universally
well-understood, though :-) ).  I have one question, though.  Of course
IKE is used by IPsec, but is it used by other application-level
protocols for key exchange?  The reason I ask is that if it's not, then
I think that would definately increase the implementation burden
if the WG decided to use it.  The reason is that while a particular
box may ship with IPsec, it won't necessarily make an API available
to where applications can use IKE directly, thus forcing implementors
to re-implement all of IKE.  Now of course you'd need to implement
all of SBSM yourself, for example, but with something like TLSM you'd
be able to make use of existing TLS libraries that are used by
plenty of applications today.

--Ken

---

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

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

    >> IKE is a well-analyzed Key Exchange protocol, whose entire job
    >> is to just authenticate end-points, agree on SA parameters and
    >> generate keys (not encumbered by other functionality).
    >> 
    >> I would strongly object to re-inventing key exchange
    >> protocol. I'd strongly support a minimal explicit interface to
    >> something like IKE.  I want to emphasize, that even INTEGRATING
    >> an EXISTING GOOD Key Exchange protocol is non-trivial and
    >> tricky enough.

    Ken> I definately agree that IKE is well-analyzed (maybe not
    Ken> universally well-understood, though :-) ).  I have one
    Ken> question, though.  Of course IKE is used by IPsec, but is it
    Ken> used by other application-level protocols for key exchange?

IKE also has an applicability statement.  IKE, particularly IKEv2 is
only for IPsec.  So, if you use IKE, expect to use IPsec.

I suggest that IPsec is a bad fit for your application.