Hello Chris, 

Yes they are. The next one will be on Friday, 20 June at 2pm (GMT+0100). 

I shall email you privately with more details. 

With Regards

Stefan



________________________________________
From: Moonshot community list [[log in to unmask]] on behalf of Chris Phillips [[log in to unmask]]
Sent: 28 May 2014 16:03
To: [log in to unmask]
Subject: Re: [eduroam-ot] Problem with RADIUS attributes 164 and 165 (RFC 7055)

Hi Alejandro & others,

Klaas sums it up well.
Your request to eduroam-ot was one of the first ones specifically asking
about moonshot and eduroam which is why it may have taken a bit of time
for a response.  As Klaas (and Miro) point out, we need to understand the
full ramifications. (e.g. Is this the ONLY thing moonshot needs from
eduroam, or is there other items to consider? What will it mean to 65+
regions operating eduroam? etc)

The number of eduroam GeGC folks on this list should signal our interest
in moonshot and is great to hear others chime in. The more moonshot is
understood of what it desires/requires of a RADIUS infrastructure, the
better we will understand what is being asked of eduroam.

Many thanks to the Alan, Scott, John, and others for their time at TNC in
Dublin on the topic. It was very helpful and look forward to continuing
the conversations..

Are the monthly moonshot community calls still being held?

Chris.
___________________________________________________________________________
________________
Chris Phillips
Technical Architect, Canadian Access Federation | CANARIE|
[log in to unmask] | W: 613.943.5370
Chair of Global eduroam Governance Committee | eduroam.org



On 14-05-28 9:11 AM, "Klaas Wierenga (kwiereng)" <[log in to unmask]>
wrote:

>On 28 May 2014, at 14:31, Alejandro Perez Mendez <[log in to unmask]> wrote:
>>
>
>Hi Alejandro,
>
>> my apologies, I probably was not clear enough in my mail. What you said
>>is exactly what I understood from Paul. My point was that, if one have a
>>situation as the one we have in the CLASSe project, where one
>>institution deploys a RP (e.g. at UMU in Spain), and other deploys an
>>IdP (e.g. at KENT in UK), the eduroam infrastructure "as is" will
>>probably fail to deliver Moonshot's attributes correctly, as packets
>>will traverse top level proxies. In that situation, as you said, one
>>need to fallback to Trust Router or another dynamic discovery method.
>>
>> I understand this does not affect to national traffic, nor specific
>>routing agreements between institutions.
>> Sorry if my mail created any confusion. That was not intended at all.
>
>and perhaps even a bit more clarification in case the perception might be
>that the GeGC is in any way ³against² MoonshotŠ. The issue here is that
>we went to great efforts to get participation policies signed by eduroam
>participants at all levels. These were all signed with a well understood
>objective in mind, namely giving users from participating institutions
>access to the network of the visited institution. Participants in eduroam
>will have had to make an assessment whether the security properties of
>the RADIUS infrastructure for eduroam are sufficient to meet the
>risk/benefit balance for  those participants. We feel that we can not
>without due process change those underlying assumptions. In other words,
>we are looking at Moonshot, and we don¹t preclude the use of the eduroam
>RADIUS hierarchy for authentication for other purposes than network
>access, but that is not a decision that can be taken lightly.
>
>Klaas
>
>>
>> Regards,
>> Alejandro
>>
>> El 28/05/14 14:20, Miroslav Milinovic escribió:
>>> Alejandro,
>>>
>>> IMO either I missunderstood you or your interpretation of the answer
>>>you got from eduroam OT is not 100% correct.
>>> I am not sure that Paul wrote that moonshot traffic is "unwanted" in
>>>eduroam infrastructure.
>>>
>>> The current position (decision) is (only) not to proxy the moonshot
>>>traffic at the eduroam top level RADIUS servers.
>>>
>>> National eduroam providers are free (and able) to permit/enable
>>>moonshot traffic nationally and internationally (via dynamic discovery
>>>methods).
>>>
>>> So, I repeat, we are not treating moonshot as unwanted in the eduroam
>>>infrastructure.
>>>
>>> I hope I clarified the matter.
>>>
>>> Kind regards
>>>
>>> Miroslav Milinovic (as European eduroam service task leader)
>>>
>>> ----- Original Message ----- From: "Alejandro Perez Mendez"
>>><[log in to unmask]>
>>> To: <[log in to unmask]>
>>> Sent: Wednesday, May 28, 2014 1:59 PM
>>> Subject: Fwd: Re: [eduroam-ot] Problem with RADIUS attributes 164 and
>>>165 (RFC 7055)
>>>
>>>
>>> FYI, eduroam AAA infrastructure does not (and will not) support
>>>Moonshot
>>> as is. They recommend using Trust Router or similar instead, to make
>>>P2P
>>> connections.
>>>
>>> Regards,
>>> Alejandro
>>>
>>>
>>> -------- Mensaje original --------
>>> Asunto: Re: [eduroam-ot] Problem with RADIUS attributes 164 and 165
>>> (RFC 7055)
>>> Fecha: Wed, 28 May 2014 12:45:36 +0200
>>> De: Paul Dekkers <[log in to unmask]>
>>> Para: Alejandro Perez Mendez <[log in to unmask]>, [log in to unmask]
>>> CC: Gabriel López <[log in to unmask]>, Rafa Marin Lopez <[log in to unmask]>, José
>>> Manuel Macías <[log in to unmask]>
>>>
>>>
>>>
>>> Hi Alejandro,
>>>
>>> Hereby a reply to your request to enable Moonshot via the international
>>> eduroam proxy infrastructure:
>>>
>>> While it is our intention to provide a transparent RADIUS proxy
>>> infrastructure for eduroam purposes, that's not the case for Moonshot.
>>> We provide the service for eduroam, and that's what NRENs/NROs signed
>>>up
>>> for and signed the policies/compliance agreements for. So even if we
>>> have the correct dictionaries installed (we're now using the late 2013
>>> versions), we consider the Moonshot requests as unexpected traffic on
>>> our proxy infrastructure.
>>>
>>> We've had discussions about this at TNC with the GeGC (Global eduroam
>>> Goverance Committee) and in the Geant eduroam steering group this
>>> morning, and decided to not permit Moonshot traffic across the
>>> international eduroam proxy infrastructure. (Whether a RADIUS service
>>>is
>>> used for more purposes within a country/region, that (and its
>>>filtering)
>>> is up to the NRO.)
>>>
>>> Moonshot is not just unexpected/unwanted traffic for some
>>>organizations,
>>> it's as I understand not the way Moonshot wants to deal with this
>>> traffic anyway: this is what the trust router is designed for. If
>>> implementing the trust router is not feasible at this time, making a
>>> direct RADIUS connection or using dynamic discovery (via NAPTR records
>>> in DNS and RadSec) would be a proper alternative, assuming that all
>>> parties involved agree.
>>>
>>> The added bonus in this approach is that there's a lot more trust in
>>>the
>>> attributes you receive. I understand the GSS-Acceptor-Realm-Name should
>>> match the realm from the originating site, but without a more direct
>>> connection this trust is relatively weak.
>>>
>>> We did consider making Moonshot routing as opt-in for the international
>>> eduroam infrastructure, but the amount of work is outblanced as this
>>> traffic would only be considered an intermediate solution until the
>>> trust router works well.
>>>
>>> I hope you understand this position and find alternative ways of
>>> interconnecting your Moonshot deployments; I'm interested in your
>>>feedback,
>>>
>>> Regards,
>>> Paul
>>>
>>>
>>> On 5-20-14 10:44, Alejandro Perez Mendez wrote:
>>>> Dear eduroam operations team,
>>>>
>>>> from the University of Murcia (UM) we are working in the GN3Plus
>>>>project
>>>> (SA5 task). Specifically, we are working on the deployment of the
>>>> Moonshot technology over the eduroam RADIUS infrastructure. In this
>>>>task
>>>> we are collaborating with the University of Kent and with RedIRIS.
>>>>
>>>> In particular, we are testing a connection between the UM and Kent,
>>>>that
>>>> uses the actual eduroam's RADIUS infrastructure to convey the Moonshot
>>>> authentication process. This connection is established as follows:
>>>>
>>>> moonshot.um.es <-> UM <-> RedIRIS <-> ETLRs <-> Janet <-> Kent <->
>>>> cs.kent.ac.uk
>>>>
>>>> However, we have having problems with the following attributes,
>>>>recently
>>>> standardized in RFC 7055:
>>>>   | GSS-Acceptor-Service-Name      | 164   | user-or-service portion
>>>>|
>>>>   |                                |       | of name
>>>>|
>>>>   |                                | |                          |
>>>>   | GSS-Acceptor-Host-Name         | 165   | host portion of name
>>>>|
>>>>   |                                | |                          |
>>>>   | GSS-Acceptor-Service-Specifics | 166   | service-specifics
>>>>|
>>>>   |                                |       | portion of name
>>>>|
>>>>   |                                | |                          |
>>>>   | GSS-Acceptor-Realm-Name        | 167   | Realm portion of name
>>>>
>>>> In particular, Moonshot includes attributes 164 and 165 on  each
>>>> Access-Request packet it generates during the authentication process.
>>>> These attributes are therefore sent from UM to Kent but, at some point
>>>> of the path, they are wrongly transcoded as Vendor(26).Ascend(529).164
>>>> and Vendor(26).Ascend(529).165. This seems to be happening since
>>>> historically Ascend used to use those codes illegally, and it seems
>>>>that
>>>> some intermediate proxy is trying to "fix" them by moving them into
>>>>the
>>>> correct namespace (i.e. as Vendor-Specific attributes). However, this
>>>>is
>>>> a mistake, as these attributes have now a standard meaning, and should
>>>> not be mangled.
>>>>
>>>> Doing our research, we've checked that neither UM nor RedIRIS are
>>>>doing
>>>> this transcoding. Kent has also verified that their organizational
>>>> server is not doing this transcoding either. And Janet claims they do
>>>> not touch these attributes. Hence, our guess is that this transcoding
>>>>is
>>>> being done at some of the ETLRs.
>>>>
>>>> Could you check this out? This should be happening on each proxied
>>>> Access-Request packet that contains [log in to unmask]
>>>> If this transcoding is happening, I'd like to request you to disable
>>>>it,
>>>> as this attributes have now been allocated by the IANA and are no
>>>>longer
>>>> in the illegal space.
>>>>
>>>> Thanks and best regards,
>>>> Alejandro
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>

Janet(UK) is a trading name of Jisc Collections and Janet Limited, a 
not-for-profit company which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238