[Nsi-wg] Question about message attrbutes..

[Inder Monga]

Jerry and John,

>> NSA-to-NSA authorization is a local implementation issue based on the 
>> establishment of trust, however, I believe Mary's accepted proposal 
>> was to do user based authorization on each message using the user 
>> context provided in the security parameters.
> Hmm...This sounds rather murky.  What do you mean based on 
> establishment of trust?   If you mean an NSA is free to accept or 
> reject another NSA's session on purely local whim (i.e. arbitrary 
> local policy) then we should be specific and clear about it.    (BTW- 
> I actually agree with this:-)
Trust could be based on a simple thing as "administrative configuration" 
or more extensive process?

Inder

>
> I presume then that there is a userid in the sessionSecurityID field 
> somewhere?    Can we spec this out in detail for the coders what the 
> "user" authorization profile info will look like in the security 
> attribute?
>
>> We really do not have the concept of a long duration session in the 
>> NSI protocol.  Each message exchange is a discrete event in which an 
>> NSA can connect, authenticate, send, and tear down the transport.
> Ok, this makes me fidgety, but its not an issue at the moment.
>
> Thanks for elaborating...all is clearer now.
> Jerry
>>
>> John.
>>
>> On 2011-08-08, at 4:01 PM, Jerry Sobieski wrote:
>>
>>> John - this may be for you...
>>>
>>> In reviewing this issue on the RA/PA... I went looking at the UML 
>>> doc Guy circulated as it is a bit easier to read than the raw WSDL...
>>>
>>> The messages all have the requesterNSAID and the providerNSAID 
>>> fields, directly folowed by the "sessionSecurityID".   This is the 
>>> only field I see for security attributes.
>>>
>>> I thought our conclusion was that there would be two security 
>>> layers: a NSA _/session/_ level authentication/authorization 
>>> credentials, and a /_request_/ level authorization credential that 
>>> would authorize the particular action requested relative to the 
>>> resource or information context of the request.  Does this 
>>> sessionSecirity field do double duty authenticating the remote NSA 
>>> *and* authorizing the particular service request?
>>>
>>> I trust the MTL to authenticate the messaging, as the NSI layer 
>>> should never see messages from an unauthenticated NSA.   But the NSI 
>>> layer does need the authorization credentials in order to properly 
>>> evaluate the primitive... The authorization of an NSI request is not 
>>> an MTL function.   So I am just a bit unsure how this field is 
>>> planned to be used within the WSDL.
>>>
>>> Thoughts/Comments?
>>> Jerry
>>> _______________________________________________
>>> nsi-wg mailing list
>>> nsi-wg at ogf.org <mailto:nsi-wg at ogf.org>
>>> http://www.ogf.org/mailman/listinfo/nsi-wg
>>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
> ------------------------------------------------------------------------
>
> John MacAuley <mailto:john.macauley at surfnet.nl>
> August 8, 2011 4:38 PM
>
>
> Jerry,
>
> We delegated the issue of NSA-to-NSA authentication to the transport 
> layer.  We will also validate message integrity and that the message 
> is coming form the expected NSA. NSA-to-NSA authorization is a local 
> implementation issue based on the establishment of trust, however, I 
> believe Mary's accepted proposal was to do user based authorization on 
> each message using the user context provided in the security 
> parameters.  We really do not have the concept of a long duration 
> session in the NSI protocol.  Each message exchange is a discrete 
> event in which an NSA can connect, authenticate, send, and tear down 
> the transport.
>
> John.
>
>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
> ------------------------------------------------------------------------
>
> Jerry Sobieski <mailto:jerry at nordu.net>
> August 8, 2011 1:01 PM
>
>
> John - this may be for you...
>
> In reviewing this issue on the RA/PA... I went looking at the UML doc 
> Guy circulated as it is a bit easier to read than the raw WSDL...
>
> The messages all have the requesterNSAID and the providerNSAID fields, 
> directly folowed by the "sessionSecurityID".   This is the only field 
> I see for security attributes.
>
> I thought our conclusion was that there would be two security layers: 
> a NSA _/session/_ level authentication/authorization credentials, and 
> a /_request_/ level authorization credential that would authorize the 
> particular action requested relative to the resource or information 
> context of the request.  Does this sessionSecirity field do double 
> duty authenticating the remote NSA *and* authorizing the particular 
> service request?
>
> I trust the MTL to authenticate the messaging, as the NSI layer should 
> never see messages from an unauthenticated NSA.   But the NSI layer 
> does need the authorization credentials in order to properly evaluate 
> the primitive... The authorization of an NSI request is not an MTL 
> function.   So I am just a bit unsure how this field is planned to be 
> used within the WSDL.
>
> Thoughts/Comments?
> Jerry
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg

-- 
Inder Monga
510-486-6531
http://www.es.net
Follow us on Twitter: ESnetUpdates/Twitter <http://bit.ly/bisCAd>
Visit our blog: ESnetUpdates Blog <http://bit.ly/9lSTO3>
Facebook: ESnetUpdates/Facebook <http://bit.ly/d2Olql>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110808/66d000b0/attachment.html