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

[Christian Groves <[e-mail]>]

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:
> 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.
[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
> 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.
[CNG] Please see my initial comments.
>   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.
[CNG] I can add something based on the outcome of our discussions.
>
> 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.
[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.
>
>
> Catherine Meadows
> Naval Research Laboratory
> Code 5543
> 4555 Overlook Ave., S.W.
> Washington DC, 20375
> phone: [phone]
> fax: [phone]
> email: [e-mail] 
> <mailto:[e-mail]>
>
_______________________________________________
secdir mailing list
[e-mail]
https://mailman.mit.edu/mailman/listinfo/secdir