Subject: RE: [midcom] Protocol Eval: 2.1.8 Mutual authentication

From: "Mary Barnes" <[email-masked]>
Date: Wed, 26 Jun 2002 10:30:59 -0500

Hi Martin,

The text for SNMP states:

" SNMPv3 partially meets this requirement. Authentication of 
    the Midcom agent is supported, but not authentication of the Midcom 
    PDP. However, SNMPv3 also contains some protection against replay 
    attacks, and when private keys are used, implicit authentication 
    can be achieved."

So, I'm not quite seeing how the proposed text (which is directly extracted
from the -00 version of the SNMP evaluation ) changes the view of SNMPv3
from being partially compliant to fully compliant.

I should also highlight that this text will be changed such that the use of
the term "MIDCOM PDP" is replaced with Middlebox, per the email thread:
http://www1.ietf.org/mail-archive/working-groups/midcom/current/msg02373.htm
l

Mary.

-----Original Message-----
From: Martin Stiemerling [mailto:[email-masked]]
Sent: Wednesday, June 26, 2002 5:17 AM
To: Barnes, Mary [NGC:B602:EXCH]
Cc: [email-masked]
Subject: Re: [midcom] Protocol Eval: 2.1.8 Mutual authentication

Mary Barnes wrote:
> Hi Martin,
> 
> I don't agree with this point.  The fact that MEGACO and DIAMETER don't
> describe their own security mechanisms, but have specified the use of
> IPSEC/TLS, does not make then Partially compliant.  It should not be a
> requirement that one of the protocols must themselves encompass the
> necessary security aspects to be Totally compliant. The MEGACO spec
clearly
> specifies the security threats and the solutions for MEGACO in the RFC
3015.
> The DIAMETER base protocol draft also specifies the use of IPSec/TLS with
a
> reasonable level of detail.  
> 
> I will change SNMP to a T if you can point out where it has the same level
> of specification on the use of IPSec.

Nothing mandates or precludes the use of IPSEC for SNMP.

Another point:
The COPS RFC 2748 says in the section 5 "security considerations" that 
COPS relies on a shared secret "To ensure the client (PEP) is 
communicating with the correct policy server (PDP) requires 
authentication of the PEP and PDP using a shared secret, [...]".
I have talked with Juergen and he mentioned that with respect to this, 
SNMPv3 supports a shared secret scheme as well. See RFC 2574 section 8 
"CBC-DES Symmetric Encryption Protocol".

So SNMP should have the same compliancy level as COPS.

> 
> Mary.
> 
> -----Original Message-----
> From: Martin Stiemerling [mailto:[email-masked]]
> Sent: Monday, June 24, 2002 7:05 AM
> To: [email-masked]
> Subject: [midcom] Protocol Eval: 2.1.8 Mutual authentication
> 
> 
> In this section COPS seems to be the only candidate which deserves the 
> 'T'. All other protocols rely on other security mechanismen, e.g. IPSEC.
> MEGACO and DIAMETER rely fully on IPSEC and they have gotten a 'T' as 
> well. But with IPSEC SNMP would deserve a 'T' as well.
> How to handle this?
> It would suggest another ranking:
> - MEGACO: 'P' because the protocol itself doesn't support mutual 
> authentication, but combined with IPSEC it can do.
> - SNMP: 'P+' because some authentication is available, but achieving a 
> full compliancy needs IPSEC, too.
> - DIAMETER: 'P' because the protocol itself doesn't support mutual 
> authentication, but combined with IPSEC/TLS it can do.
> 
> We should take into account that any protocol will fit to this 
> requirement when the use of IPSEC/TLS makes a 'T' status.
> 

-- 
Martin Stiemerling

NEC Europe Ltd. -- Network Laboratories  [email-masked]
IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 26 Jun 2002 18:58:14 +0200

Mary,

I guess it was my initial bad phrasing of the SNMP evaluation
I should have stated that there is IMPLICIT MUTUAL authentication
included in SNMPv3:

SNMPv3 supports 2 levels of authentication: system based
and user based:

SNMPv3 explicitly supports symmetric secret key encryption
between Midcom agent (SNMP manager) and Middlebox (SNMP agent).
The encryption method is specified in RFC 2574. As the
original text says, this can be used for implicit authentication.
I should have added: MUTUAL authentication. When the message
cannot be decrypted with the shared secret the authentication
fails.

Beyond this SNMPv3 supports user authentication. Different
users at the same management application (Midcom agent)
can authenticate themselves with one of two authentication
methods (also specified in RFC 2574). Just this
authentication is not mutual.

Now Martin found that COPS authentication is also based
on a shared secret and is probably comparable to the
implicit mutual one in SNMP.

I hope these words clarify more than they confuse the
discussion, but I am not sure ;-)

    Juergen
-- 
Juergen Quittek     [email-masked]     Tel: +49 6221 90511-15
NEC Europe Ltd.,    Network Laboratories     Fax: +49 6221 90511-55
Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de

--On 26 June 2002 10:30 -0500 Mary Barnes <[email-masked]> wrote:

> So, I'm not quite seeing how the proposed text (which is directly extracted from the -00 version of the SNMP evaluation ) changes the view of SNMPv3 from being partially compliant to fully compliant.
>
> I should also highlight that this text will be changed such that the use of the term "MIDCOM PDP" is replaced with Middlebox, per the email thread:
>
> http://www1.ietf.org/mail-archive/working-groups/midcom/current/msg02373.html
>
> Mary.
>
>> necessary security aspects to be Totally compliant. The MEGACO spec clearly
>> specifies the security threats and the solutions for MEGACO in the RFC 3015.
>> The DIAMETER base protocol draft also specifies the use of IPSec/TLS with a

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