[Ipsec] RE: Please review draft-ietf-msec-ipsec-extensions-04 (fwd)

[<Pasi.Eronen@xxxxxxxxx>]

George Gross wrote:

> > 2) Section 4.1.3.1: "An implementation SHOULD offer PAD
> > configuration capabilities that authorize the GKM policy
> > configuration mechanism to set security policy for other aspects
> > of an endpoint's GSPD/SAD configuration, not confined to its group
> > security associations. This capability allows the group's policy
> > to inhibit the creation of back channels that might otherwise leak
> > confidential group application data."
> >
> > I didn't quite understand this; a more detailed description might
> > be helpful...
> 
> What this was intended to enable are security policies that would
> use the SPD-O DISCARD processing option to prevent an insider
> Adversary from re-broadcasting (either multicast or unicast) the
> group's data (e.g. a pay-per-view content). I don't know if
> explaining that helps answer your question though...

What kind of insider you're considering here? If a rogue application
gets the data, I can't see how anything in the SPD/PAD short of
"discard all outgoing traffic" would prevent it from sending it to
someone else.

(Of course, there may be operation system/virtual machine level
security mechanisms that limit what an application can do (like
permissions in Java), but that's not part of SPD/PAD.)

While the Group Owner can choose the policy for that group, I'm not
sure if we want to have a "SHOULD"-level feature that would allow any
group owner to override all IPsec policies of a host (which are 
set by the host owner/administrator/whatever, not the group owner.)

> > 3) Appendix A.2 seems to suggest that GKM can also set up unicast
> > IPsec SAs? ("However, the unicast inverse flows can use the group's
> > IPsec group authentication mechanism.") This text needs 
> > clarification.
> 
> One of the use cases is NORM, which does multicast from the Group
> Speaker to the Group Receivers, and unicast from Group Receiver(s)
> to the Group Speaker. The unicast messages include NACK repair
> requests, congestion control metering, and other session control
> messages. Would it help if we explicitly mentioned that NORM would
> fit into this use case?

Mentioning NORM might help, but the important thing to mention (if it
is really the case) is that GKM can create unicast SAs. This
complicates several things, such as SPI selection (which would
need to be coordinated with the unicast key management subsystem).
Currently, the draft does not seem to consider these issues.

Best regards,
Pasi

_______________________________________________
Ipsec mailing list
Ipsec@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ipsec