Subject: Re: Queries regarding Security in MEGACO

From: Prashant Jain <[email-masked]>
Date: Tue, 2 Nov 1999 09:27:25 +0530

hi brian,

We had sent a mail earlier regarding some security issues. I am forwarding that
mail since we did not get any reply from anybody (may be some problem with our
mail server as it was down for last few days).

Please do reply and give suggesstions on the issues in the following mail.

regards,

-Prashant Jain
( for Gateway Team, Hughes Software Systems)

-------------------------------------------------- Forwarded
mail-----------------------------------------------------------------------------------
hi brian,
Thanks for the reply. I have few more doubts, marked by <PJ> below.

Brian Rosen <[email-masked]> on 10/25/99 01:35:25 AM

To:   Prashant Jain/HSS@HSS
cc:   "Megaco (E-mail)" <[email-masked]>

Subject:  RE: Queries regarding Security in MEGACO

> 1. Would the Interim AH-within-MEGACO scheme assumes that the
> implementation of
> security protocols (AH or ESP) in MEGACO
> should completely follow the guidelines mentioned in the
> rfc2401 (Security
> Archetecture for Internet Protocol).
The present text does not specify that it should.
The guidelines are just that, guidelines.  I recommend them to you,
but they are not required.

<PJ> ok fine. But, protocol draft should mention to what extent the guidelines
should be followed.After gone through the rfc2401 to 2411, one can find the
following implementation issues:
     1. How to decide upon the scope of Security policy (whether based on MG-MGC
association or         some other method).
     2. creation of SAD that shall contain all the information i.e., Security
Protocol to be              Used,encrption algorithm, keys for AH checksum, SPI
(Security Parameter Index). I think         that is simple since we are having
TCP/UDP as transport (rfc2401) so the SAD shall be              created when the
TCP/UDP sockets are opened.
     3. Whether to use manual keys provisioning or to have dynamic key
management using IKE.
        Now, if the protocol does not specify any one method to be followed,
then the               inoperability issues may arise since one entity (MG/MGC)
may be supporting manual              configuration but corresponding remote
entity( MGC/MG) may be requring dynamic key           management.This scenario
may result into complicated interoperability issues.

     4. Similar interoperability issues may arise on how to exchange other SAD
                  information (SPI in AH header, encrp.algorithms for ESP) which
are required for the AH     header preparation for megaco messages at the
sending end and to handle the INBOUND            messages received (i.e.header
checksum verification using crpt. keys, decryption of ESP       payload etc.) at
the remote end.

Therefore to take care of these issues, protocol should clearely specify the
requirements of AH-within MEGACO and should not leave the implemetation issues
at the wish of user. We think if the protocol mentions these implementation
Requirements, then the guidelines for IPSEC implementation for AH-within MEGACO
would be explicitly clear.

> 2. rfc2401 says that the implementation should have a
> Security Policy Database
> (SPD) and a Secuirty Association Database.
> The SPD describes the security policies ( Security Protocols
> ( AH or ESP),
> Crptographic keys, algorithms required to be used) to be used
> for  IP traffic.
> And the SAD signifies the active instantiation of a
> particular entry in SPD.
>      So, the query is whether the security policies should be
> decided based on
> MG-MGC association or some other criteria should be used. If
> the policy is
> association based, then whether the Security arributes
> (Security protocol, keys
> algorithms) shall be manually configued in MG/MGC or they
> will be negociated
> using ISAKMP protocol ?.
This is implementation dependent.  It is recognized that the necessity
to implement the interim scheme is driven by the inability to obtain
a full IPSEC implementation for the o/s.  In this case, it may be
difficult to reproduce the entire IPSEC mechanism.  A manual mechanism
may be appropriate, although if at all possible, a more dynamic mechanism
using, for example, IKE is preferred of course.  Personally, I would
try to maintain a SAD, and implement IKE if at all possible.  SPD would
be ideal, of course, but a full IPSEC implementation, with a policy
infrastructure is the real goal.

<PJ> This may cause interoperability problems as mentioned above. We think the
protocol should mention what should be supported instead of mentioning the
various possibilities.

> 3. How the SPD and SAD for the INBOUND ( data coming from
> network at the host)
> traffic be created since rfc2401 addresses the need of
> separate databases for
> INBOUND and the OUTBOUNG traffic ?.
If using IKE, I believe this can be accomodated.  Manual keying is
of course easy.

<PJ> Using IKE, keys can only be exchanged not the SA information (apart from
keying). It needs the implementation of full ISAKMP protocol for dynamic
exchange between MG-MGC.

> 4. Whether the SPD and SAD databases shall be same, if the
> Security policy is
> based on MG-MGC association ?.
Generally, the MG is a slave, and it is unlikely to have a security
policy of it's own.  The MGC is more likely to have a security policy.
Nothing prevents the MG from having a policy.  If the policy was dynamic,
as the standards envision, then there would be an SPD.

The SAD is independent, I would say, and is more related to whether
the keying is static or dynamic.  Since an MG generally has only one MG MGC
association, it may not need a SAD.  An MGC will often have multiple
associations, and thus it's need for a SAD is more likely.

If at all possible, use real IPSEC.

Regards,
Prashant Jain
Hughes Software Systems

---

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 3 Nov 1999 08:14:03 -0500

I tend to agree with Brian that it is wrong to nail down security management
capabilities to the extent you are asking.  The real recommendation is to
offer full IPSEC if you can.  If you can't, then you are offering a product
customers may find deficient.  The amount of deficiency can't be policed by
Megaco because different vendors are building on different platforms (which
is why the problem arose in the first place).  The market will decide
whether any particular product is deployable.

Your first two items may merit a few words of additional explanation in the
document.

        [[TomT]]  ...
> TCP/UDP sockets are opened.
        [[TomT]]  These two might justify some more discussion in the
protocol document.