Per-Entity Metadata Working Group

[Paul Caskey <>]

For signature verification, I guess ADFS could need to continue following the 
script approach to manually verify the signature and import metadata into 
ADFS (FEMMA, etc).

I see Msft still has this article out there: 
https://technet.microsoft.com/en-us/library/gg317734(v=ws.10).aspx



> -----Original Message-----
> From: 
> 
>  
> [mailto:]
>  On Behalf Of Tom
> Scavo
> Sent: Friday, September 09, 2016 8:53 AM
> To: Cantor, Scott 
> <>
> Cc: Thomas Scavo 
> <>;
>  Per-Entity Metadata Working
> Group 
> <>
> Subject: Re: [Per-Entity] deploying TLS on the MDQ server
> 
> On Fri, Sep 9, 2016 at 9:40 AM, Cantor, Scott 
> <>
>  wrote:
> > On 9/9/16, 9:31 AM, 
> > "
> >  on behalf of Tom Scavo"
> <
>  on behalf of 
> >
>  wrote:
> >
> >>    Can you be more specific about what you think is "tight enough?"
> >
> > I haven't thought about it, but in giving a little bit of consideration 
> > to it, I
> don't know if there is anything realistic that would help given the sort of
> attack I'm thinking of. Certainly hours at most, but really the attack just
> requires that the window between "it changed" and "it gets requested" is
> wider than real time. So I suppose I think TLS is basically a requirement 
> in the
> end.
> >
> >> I'm not following you. On the production side, aggregates and
> >> entities are identical since they emanate from the same
> >> infrastructure. On the client side, request patterns are different, I
> >> realize that, but I don't see how that influences validUntil. I think I'm
> missing something.
> >
> > The difference is in the knowledge the attacker has of when the request
> for the metadata might be made. Because it's an active attack, knowing
> when the request will be made is pretty significant in pulling something off
> that requires actively intercepting and changing/substituting a result.
> 
> Okay, putting both of those together, I conclude we need TLS on the MDQ
> server to address your concern (and it has nothing to do with validUntil). 
> But
> what about the other scenario? What can/should we provide to AD FS (which
> currently has no security options whatsoever)?
> 
> Tom