Subject: [secdir] secdir review of draft-groves-megaco-pkgereg-02

From: Catherine Meadows <[email-masked]>
Date: Fri, 6 Feb 2009 11:34:17 -0500

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This draft concerns the H.248/MEGACO IANA Package Registration
procedures.  It updates the procedure so that a formal review step,  
since the IETF Megaco
working group, which previously did an informal review, is now  
disbanded.

Since this merely updates the package review process to include a  
formal review, the ID claims
that this introduces no extra security concerns, other than to require  
that the requester of a review
and registration of a package is authorized to do so.  However, I  
wonder if it would be appropriate
to include some language saying that the review process should address  
any potential security
concerns a package may introduce.  I am not an expert on this  
protocol, but  packages appear to be fairly
complex structures that support terminations, which are sources and/or  
sinks. Ambiguity in packages
would be a security concern (possibly allowing spoofing, if I  
understand this correctly);  this
is already covered in the review process recommended in this ID.   I  
would like to see more justification
in the security concerns section that this is the *only* security  
concerned introduced by new packages
before I feel comfortable with this.

The ID says that security concerns for the H.248/MEGACO protocol
are  discussed in H.248.1 section 10.  Note that this itself
appears to be a draft .  Also, it only discusses security in an IP  
setting. That should presumably not be a problem
for the IETF, since that is what we are concerned about, but it should  
still be mentioned, so that the
reader doesn't think that document covers security in general.

Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email: [email-masked]

_______________________________________________
secdir mailing list
[email-masked]
https://mailman.mit.edu/mailman/listinfo/secdir

---

From: Catherine Meadows <[email-masked]>
Date: Fri, 6 Feb 2009 11:50:47 -0500

My apologies, I sent this to the old secdir address my mistake.

Cathy

Begin forwarded message:

> From: Catherine Meadows <[email-masked]>
> Date: February 6, 2009 11:34:17 AM EST
> To: [email-masked], [email-masked], [email-masked] 
> , [email-masked], [email-masked]
> Cc: Catherine Meadows <[email-masked]>
> Subject: secdir review of draft-groves-megaco-pkgereg-02
>
> that this introduces no extra security concerns, other than to  
> require that the requester of a review
> to include some language saying that the review process should  
> address any potential security
> complex structures that support terminations, which are sources and/ 
> or sinks. Ambiguity in packages
> for the IETF, since that is what we are concerned about, but it  
> should still be mentioned, so that the

Catherine Meadows

---

From: Christian Groves <[email-masked]>
Date: Fri, 13 Feb 2009 11:57:35 +1100

Hello Catherine,

Thankyou for the review of the draft. You are correct that the draft 
basically introduces a formal review step for PackageID allocations.

In developing the draft I took the assumption that the use of packages 
(and associated PackageID allocation) has been a long established 
practice. Therefore I didn't delve into protocol operation. Whilst 
packages may define extra procedures and codepoints these are done 
within the framework of the core protocol specfication. It is not 
possible to update the core protocol through a package specification. 
The use of the H.248.1 core protocol is agreed between a MGC/MG. H.248 
ServiceChange procedures establish a H.248 control association between 
the MGC/MG. To establish an association there must be a level of trust 
between the MGC/MG. In the context of this control association (and 
trust) the elements (properties/signals/events/statistics) from the 
Packages are conveyed between the MGC and MG. An MGC/MG will only act 
upon elements that it knows. If it does not understand an PackageID or 
package element then an error response is returned only in the context 
of the control association.

So if someone wrote a malicious Package Specification and implemented it 
in a MGC or MG it would be unlikely to cause problems. As H.248 is a 
master slave protocol if the malicious package was implemented in the 
MGC and not the MG there would be no action because the MG would not 
understand the PackageID (and elements). If the malicious package was 
implemented on the MG there would be no affect because the MGC would 
never command the MG to use it. If the malicious package was implemented 
in both the MGC and MG then there's a wider non-H.248 issue that someone 
has managed to install software on both the MGC and the MG. It is highly 
unlikely for such a person to ask IANA for a PackageID when they could 
use any one they want. Indeed the allocation of "Private" PackageIDs 
with little review is allowed.

Keeping this is mind I'm not sure that I understand your point with 
regards to ambiguity leading to spoofing. Could you elaborate?

Please see some further comments below.

Regards, Christian

Catherine Meadows wrote:
> concerns a package may introduce.
[CNG] I can add some general text to say that the reviewer should 
address any potential security concerns.
>  I am not an expert on this protocol, but  packages appear to be fairly
> is already covered in the review process recommended in this ID.
[CNG] Please see my initial comments.
>   I would like to see more justification
[CNG] I can add something based on the outcome of our discussions.
> reader doesn't think that document covers security in general.
[CNG] With regards to H.248.1 being a draft, it is an approved document. 
It is state "pre-published" for editorial reasons i.e. translation must 
be done etc. The technical content does not change. With regards to 
H.248.1 section 10 being IP specific yes I agree I can add some text to 
this effect.
> <mailto:[email-masked]>
>