InCommon Technical Discussions

[Nick Roy <>]

On 11/15/17 9:28 AM, Nick Roy wrote:
> Hi,
>
> On 11/15/17 8:25 AM, Steven Carmody wrote:
>> I think InCommon is already past the point where the "profile" of a
>> typical installation/site/sysadmin has drastically changed from the
>> early days. Growth has brought changes. A major implication of that
>> statement is that the type of documentation that IC provides will have
>> to change. The TAC was recently discussing whether its now reasonable
>> to expect that a campus sysadmin would know how to "create" a local
>> proxy server.
> The comment about proxying here needs a bit of context wrapped around it
> to avoid confusion.  It was simply a statement by me that we have heard
> people saying they cannot deal with downloading the existing metadata
> aggregate over vanilla HTTP/port 80.  I had assumed that meant they
> wanted TLS, and I suggested that if they wanted TLS, they could set up a
> cron job or something to do a GET of the metadata, run it through
> XMLsectool to do signature verification (since I assumed whatever they
> were running probably couldn't verify the signature on the metadata) and
> then republish it to their metadata clients over whatever channel they
> desired.  It had nothing to do with running a SAML proxy.

To further clarify, it turned out that this had nothing to do with
wanting TLS, it was that the affected sites' security people would not
allow outbound traffic on port 80, so they were blocked by their own
firewall rules.

Nick

>
> Nick
>
>
>> The errorURL documentation is another example of this question -- I
>> believe its exhaustively documented for some sysadmins, but
>> under-documented for a growing proportion of the IC member sites.
>>
>> re "I would suggest that the community start working groups ... to
>> determine what the requirements are"
>>
>> I think that's a great idea, but I'm not aware of any process that
>> could be used to do that.
>>
>> Since this is a Policy Issue, shouldn't the AAC create a WG ?
>>
>> On 11/14/17 3:52 PM, Nick Roy wrote:
>>> The errorURL is exhaustively documented at:
>>>
>>> https://spaces.internet2.edu/display/InCFederation/Error+Handling+URL
>>>
>>> The mdui:PrivacyStatementURL is less thoroughly documented in the
>>> following places:
>>>
>>> IdP:
>>> https://spaces.internet2.edu/display/InCFederation/IdP+User+Interface+Elements#IdPUserInterfaceElements-IdPPrivacyStatementURL
>>>
>>>
>>> SP:
>>> https://spaces.internet2.edu/display/InCFederation/SP+User+Interface+Elements#SPUserInterfaceElements-SPPrivacyStatementURL
>>>
>>>
>>> The SP privacy statement documentation offers a bit of a chicken-and-egg
>>> problem in that it refers to the POP, which will be deprecated by
>>> Baseline Expectations.
>>>
>>> If the community wants guidance on what it expects of itself in these
>>> documents, I would suggest that the community start working groups or
>>> something to determine what the requirements are.  The 'testables' that
>>> InCommon operations will be checking for are merely the existence of the
>>> relevant URLs in metadata and that they give an HTTP 200 in response to
>>> a GET.
>>>
>>> Nick
>>>
>>>
>>> On 11/14/17 1:45 PM, Steven Carmody wrote:
>>>> I assume IC will be providing guidance for both the Privacy Statement
>>>> and the errorURL page ?
>>>>
>>>> I think IC should list the points related to Federated Authentication
>>>> that should be covered in the Privacy Statement, while making it clear
>>>> that this list is a minimum, and other topics can also be addressed.
>>>>
>>>> With the errorURL page, I think IC could be rather specific in its
>>>> suggestions about both content and layout, in order to achieve some
>>>> level of consistency from site to site.
>>>>
>>>> Without some guidance, I think we'll merely repeat our experience with
>>>> the LOGO images.
>>>>
>>>> On 11/10/17 4:09 PM, Nick Roy wrote:
>>>>> Here's an updated version of the wiki, please review:
>>>>>
>>>>> https://spaces.internet2.edu/x/4RL9Bg
>>>>>
>>>>> Nick
>>>>>
>>>>> On 11/10/17 8:52 AM, Nick Roy wrote:
>>>>>> Nice
>>>>>>
>>>>>> I'm going to collate all the info from this discussion and update the
>>>>>> wiki page and our internal gdoc with the info today.
>>>>>>
>>>>>> Nick
>>>>>>
>>>>>> On 11/10/17 8:35 AM, David Shafer wrote:
>>>>>>> FYI, here is Facebook’s policy for app icons, which seems to work
>>>>>>> pretty well:
>>>>>>>
>>>>>>> “4. Icons:
>>>>>>> a. Use a transparent or colored background. If your icon requires a
>>>>>>> white background, use a colored border.
>>>>>>> b. If your logo has a drop shadow, use a colored background.”
>>>>>>>
>>>>>>> https://developers.facebook.com/policy/
>>>>>>>
>>>>>>> Dave
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: 
>>>>>>> <>
>>>>>>>  on behalf of Nick
>>>>>>> Roy 
>>>>>>> <>
>>>>>>> Date: Thursday, November 9, 2017 at 4:05 PM
>>>>>>> To: Chris Phillips 
>>>>>>> <>,
>>>>>>>  "Farmer, Jacob"
>>>>>>> <>,
>>>>>>>  "Cantor, Scott" 
>>>>>>> <>,
>>>>>>> ""
>>>>>>>  
>>>>>>> <>
>>>>>>> Subject: Re: [InC-Technical] InCommon Baseline Expectations
>>>>>>> Metadata Requirements
>>>>>>>
>>>>>>>       I'll point out that the SSL test is a *recommended* piece but
>>>>>>> *not
>>>>>>>       required* in the current specification of Baseline
>>>>>>> Expectations.
>>>>>>>            To restate what I've heard so far:
>>>>>>>            Logo URL:
>>>>>>>            - results in a 200 via HTTP GET
>>>>>>>       - is a PNG with a transparent background / alpha channel
>>>>>>> (because JPG
>>>>>>>       does not support transparency)
>>>>>>>       - is 80w x 20h
>>>>>>>            SSL for endpoints:
>>>>>>>            - subject to InCommon operations' running of SSL scans
>>>>>>> (exact nature to
>>>>>>>       be determined by operations)
>>>>>>>       - operations may save and act on information about the quality
>>>>>>> of SSL at
>>>>>>>       its discretion
>>>>>>>            (no minimum grade or other requirement related to SSL)
>>>>>>>            errorURL:
>>>>>>>            - results in a 200 via HTTP GET, other results cause a
>>>>>>> warning but not a
>>>>>>>       full failure of the baseline tests
>>>>>>>       (do we need to say something about 302 and maximum depth to
>>>>>>> chase
>>>>>>>       referrals before lack of a 200 causes failure?)
>>>>>>>            How does that look?
>>>>>>>            Thank you,
>>>>>>>            Nick
>>>>>>>            On 11/9/17 8:47 AM, Chris Phillips wrote:
>>>>>>>       > Great dialogue on this.
>>>>>>>       >
>>>>>>>       > Maybe it would be better to define what’s not acceptable
>>>>>>> regarding a grade and what’s a reasonable duration to remediate.
>>>>>>>       >
>>>>>>>       > Highest grade (A+) preferred but no lower than C on ssllabs
>>>>>>> and no longer than say X days below this band of acceptance.
>>>>>>>       >
>>>>>>>       > This gives latitude to maneuver when the tools change
>>>>>>> underneath one’s feet and dependencies to catch up.
>>>>>>>       > Jacob’s example is great in this regard. If his group didn’t
>>>>>>> care about it (or know to test that way) then how would he have
>>>>>>> pushed for the change to get back into compliance and hence
>>>>>>> pressured the vendor to step up?
>>>>>>>       >
>>>>>>>       > That said, things like Poodle SSLv3 and other future events
>>>>>>> we know will happen will change ranking from A+ to F overnight.
>>>>>>> Using the idea of X days to come into compliance allows us to
>>>>>>> respond commensurate with the risk.  It also allows us to simply be
>>>>>>> users of the tool which is not our core mission – we just want the
>>>>>>> output to inform our decisions.
>>>>>>>       >
>>>>>>>       >
>>>>>>>       > C
>>>>>>>       >
>>>>>>>       > On 2017-11-09, 9:53 AM, "Farmer, Jacob"
>>>>>>> <
>>>>>>>  on behalf of
>>>>>>> >
>>>>>>>  wrote:
>>>>>>>       >
>>>>>>>       >     Nick,
>>>>>>>       >
>>>>>>>       >     I like the Qualys SSL scanner and we use it often. Given
>>>>>>> my history, though, I
>>>>>>>       >     am reluctant to rely on it for this kind of thing. A
>>>>>>> real-world story from the
>>>>>>>       >     last few years: Qualys made a change to the scanner
>>>>>>> which caused sites we
>>>>>>>       >     manage that were in the A range to fall into the B+
>>>>>>> range. I don't recall all
>>>>>>>       >     of the details about why; I think it had to do with
>>>>>>> cipher suites. Our load
>>>>>>>       >     balancer -- a widely deployed product on its current
>>>>>>> version -- could not be
>>>>>>>       >     adjusted to bring it back up to A. There was something
>>>>>>> in the configuration
>>>>>>>       >     that Qualys simply didn't like and there was no way to
>>>>>>> fix it until a vendor
>>>>>>>       >     patch shipped.
>>>>>>>       >
>>>>>>>       >     I'm glad that we took the time to get it figured out,
>>>>>>> but I also don't think
>>>>>>>       >     that the quality of SSL was meaningfully degraded in the
>>>>>>> interim.
>>>>>>>       >
>>>>>>>       >     I support the idea of defining "good TLS" but I am
>>>>>>> reluctant to rely on this
>>>>>>>       >     scanner to define it.
>>>>>>>       >
>>>>>>>       >     Jacob
>>>>>>>       >
>>>>>>>       >     -----Original Message-----
>>>>>>>       >     From: 
>>>>>>> 
>>>>>>>       >     
>>>>>>> [mailto:]
>>>>>>>  On
>>>>>>> Behalf Of Nick Roy
>>>>>>>       >     Sent: Wednesday, November 8, 2017 4:59 PM
>>>>>>>       >     To: Cantor, Scott 
>>>>>>> <>;
>>>>>>> 
>>>>>>>       >     Subject: Re: [InC-Technical] InCommon Baseline
>>>>>>> Expectations Metadata
>>>>>>>       >     Requirements
>>>>>>>       >
>>>>>>>       >
>>>>>>>       >
>>>>>>>       >     On 11/8/17 1:58 PM, Cantor, Scott wrote:
>>>>>>>       >     >> RECOMMENDED:
>>>>>>>       >     >>
>>>>>>>       >     >>    SSL certificates on endpoints are valid
>>>>>>>       >     > That seems like a slippery slope: valid re: dates?
>>>>>>> Specific CAs? Key sizes?
>>>>>>>       >     > What about ciphers, or use of TLS 1.0, etc.?
>>>>>>>       >     >
>>>>>>>       >     > Requiring a logo is, I think, underspecified, we
>>>>>>> should mandate specific
>>>>>>>       >     > size(s).
>>>>>>>       >     >
>>>>>>>       >     > I'd like to see errorURL be required with guidance
>>>>>>> around what should be
>>>>>>>       >     > behind it.
>>>>>>>       >
>>>>>>>       >     We think errorURL should be included as well, but since
>>>>>>> it was not part of the
>>>>>>>       >     'required' elements that AAC specified (AAC assumed
>>>>>>> errorURL was part of the
>>>>>>>       >     mdui: information, and it is not) that means this would
>>>>>>> have to go back to ACC
>>>>>>>       >     to make errorURL a separate required element.
>>>>>>>       >
>>>>>>>       >     Agree re: specific requirements for SSL and logo.
>>>>>>>       >
>>>>>>>       >     Here is my proposed requirement for SSL for endpoints
>>>>>>> (since it's recommended
>>>>>>>       >     but not required):
>>>>>>>       >
>>>>>>>       >     - Achieve a grade of A on the Qualys SSL scanner [1]
>>>>>>>       >
>>>>>>>       >     And for HTTPS Logo URL:
>>>>>>>       >
>>>>>>>       >     - Must result in an HTTP 200 in response to a GET
>>>>>>> request
>>>>>>>       >     - Image must be either a PNG or JPG
>>>>>>>       >     - Image must be 80 pixels in width by 60 in height
>>>>>>>       >
>>>>>>>       >     [1]
>>>>>>> https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide
>>>>>>>       >
>>>>>>>       >     Let me know if you think this is something that would
>>>>>>> better be discussed in
>>>>>>>       >     detail by the Ops Advisory Group or in some other venue.
>>>>>>>       >
>>>>>>>       >     Thank you,
>>>>>>>       >
>>>>>>>       >     Nick
>>>>>>>       >
>>>>>>>       >     >
>>>>>>>       >     > -- Scott
>>>>>>>       >     >
>>>>>>>       >     >
>>>>>>>       >
>>>>>>>       >
>>>>>>>