[voms-proc-wg] [Nsi-wg] OGF NSI networking architecture and need for certificates with restricted user base

Thu Aug 7 04:03:58 EDT 2014

Hi Henrik, all,

On 06/08/14 15:12, Henrik Thostrup Jensen wrote:
>
> First, a +1 on what Mischa Salle wrote.
>
> There are several misconceptions in the presentation: Presenting the
> java trust/key store as a TLS protocol concept, client certificates
> should probably be host certificates, though the difference is limited
> to some certificate attributes.
>
> The boxed text on slide 11 seems to be the main "problem" in the
> presentation. However it is a fundemental concept of PKI, and it is
> NOT a weakness or a problem. I know some TLS implementations tend to
> hide the DN or make it overly complicated to get it, which is pretty
> bad (generally wrappers for http clients). The whole thing seems like
> an eloborate attempt to overcome this problem.
>
> The suggestion to use self-signed certs essentially makes authN and
> authZ the same thing removing the need to do any in-app checking. This
> is extremely inflexible though and just moves the AuthZ to TLS
> certificate configuration (which is not where it is supposed to be),
> while adding manual certificate handling.
>
> Finally it also unenforceable and the options does not exclude each
> other. GEANT and NORDUnet uses TERENA certs (and I doubt that will
> change), where SURFnet uses self-signed certs.

Just to be correct, from the start SURFnet has been using TERENA
certificates to secure NSI control plane session.

> Yet the NSI agents of these networks trust each other and communicate
> just fine. Personally I only add the needed CAs to the NORDUnet NSI
> Agent CA list, as there have been a bit too many CA slips recently.
>
> The first point on slide 16 is complete bullshit (and manipulative).
> While PKI isn't perfect, switching to a fully manual self-signed setup
> is extremely error-prone as it is generally difficult to manage
> certificates.
>
> Finally: Why exactly do we need to standardize how NSI agents thrust
> each other besides what is mentioned in the NSI Security section?

That was always my intention, and that is why the text is phrase as it
is right now. How particular deployments want to implement control plane
security is up to them, I do not want to enforce the use of self-signed
certs or the use of any particular CA or rules on what attributes need
to be checked or not. What I do expect to happen, if for example NSI is
deployed in a grid environments, is that NSAs will most likely start
using existing CA infrastructure and existing attributes to check, just
because it is already there and convenient to use. But in general, the
whole idea is that you decide with your peer what means of authorization
is sufficient to you both, and if it is acceptable to you this can mean
that you will have different ways to authorize different peers.

Cheers,
    HansT.

>
>
> On Wed, 30 Jul 2014, Sill, Alan wrote:
>
>> Dear folks in the OGF CAOPS, VOMS-PROC and NSI working groups.
>> I'd like to initiate some discussion among the participants in these
>> working groups for the use case
>> referred to in the talk at the link below. 
>>
>> Some review of the conditions for this use case would be helpful.
>> Note this is also a use case that
>> comes up in Internet-of-Things discussions, and has caused some
>> discussion on the PKIX group list
>> (though that group is now dormant of course) and other related lists
>> lately.
>>
>> To me this is a familiar situation with well-known parameters, but
>> possibly some additional
>> considerations, and might possibly lead to some useful communication
>> among the members in these groups
>> about solutions that could be applied using existing technologies
>> that would avoid the possible
>> downsides associated with the proposed use of self-signed
>> certificates. (For example, extended
>> attribute certificates as used in VOMS, though the same or perhaps
>> through a different implementation,
>> might be a good solution here; other solutions might be contemplated
>> that would be more attractive than
>> self-signed certificates for this situation.)
>>
>> Your comments, discussion and input are recruited (by me -- I'm not
>> speaking for the NIS-WG members per
>> se!), and I hope that all parties will regard this as useful
>> discussion for information exchange only.
>>
>> Thanks,
>> Alan
>>
>> Begin forwarded message:
>>
>>       From: Guy Roberts <Guy.Roberts at dante.net>
>> Subject: RE: [Nsi-wg] Wednesday's NSI conf call
>> Date: July 30, 2014 at 1:30:19 PM GMT+2
>> To: Alan Sill <kilohoku150 at gmail.com>
>>
>> Hi Alan,
>>  
>> Please find the slides on NSI security here:
>>  
>> https://redmine.ogf.org/dmsf/nsi-wg?folder_id=6592
>>  
>> The proposal is that  NSAs will run their own private Certificate
>> Authorities (self-signing)
>> rather than using public Certificate Authorities.  Participating NSAs
>> will then exchange
>> information about  each other's Certificates in an ad hoc way.
>>  
>> This solution does not scale well as private Certificates have to be
>> manually shared, but it
>> reduces the size of the certificate pool.
>>  
>> Guy
>>  
>> From: Alan Sill [mailto:kilohoku150 at gmail.com] 
>> Sent: 30 July 2014 10:56
>> To: Guy Roberts
>> Cc: Alan Sill
>> Subject: Re: [Nsi-wg] Wednesday's NSI conf call
>>  
>> Guy,
>>  
>> On Jul 30, 2014, at 11:02 AM, Guy Roberts <Guy.Roberts at dante.net> wrote:
>>
>>  
>>
>>       - comments/feedback from last week's presentation from John on
>> 'Secure Communications
>>       with Self Signed Certificates'
>>
>>  
>> Are copies of these slides available? I would like to understand the
>> context.
>>  
>> (In general, use of self-signed certificates is risky at best, so I
>> would like to understand the
>> use case here.)
>>  
>> Alan
>>
>>
>>
>>
>
>
>     Best regards, Henrik
>
>  Henrik Thostrup Jensen <htj at nordu.net>
>  Software Developer, NORDUnet
>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/voms-proc-wg/attachments/20140807/f1675a85/attachment.html>