Subject: [NSIS] NATFW+AUTH_SESSION: Scenarios with multiple authorization tokens

From: Matthias Friedrich <[email-masked]>
Date: Wed, 18 Oct 2006 17:23:28 +0200

Hi,

I think one AUTH_SESSION object isn't enough. Consider the following
scenario, for example:

A trusted party inside the NR's domain ("receiver domain") issues an
autorization token (in AUTH_SESSION syntax). It is passed to the NI
which has to include it in CREATE messages. Otherwise the NFs inside the
receiver domain won't let the message pass.

Now suppose the sender domain also relies on AUTH_SESSION objects.
Local NFs only accept messages if they contain authorization tokens
issued by a trusted party from the sender domain. The usage of a token
has the advantage that it can be granted on a user basis. In contrast,
an NF querying a policy server based on a NATFW message has no user
information available and can only make a decision based on addresses.

So we have two tokens (and thus two AUTH_SESSION objects) but only one
ID, according to draft-manner-nsis-nslp-auth-01, Section 7. To cover
this use case, I think we either have to assign multiple IDs or extend
AUTH_SESSION to carry multiple (authorizing entity, signature) pairs.

Regards,
	Matthias

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 18 Oct 2006 22:51:10 +0300 (EEST)

Hi,

I'll let the NATFW authors answer to your detailed question.

Still, as an overall comment, if you think multiple authentication pairs 
should be possible, then we could just allow multiple AUTH_SESSION objects 
within a single message. However, how do we define, which entity checks 
which token?

Jukka

---

From: Matthias Friedrich <[email-masked]>
Date: Thu, 19 Oct 2006 10:02:06 +0200

Hi,

thanks for your reply. Comments inline.

On Wednesday, 2006-10-18, Jukka MJ Manner wrote:
[...]
> within a single message. However, how do we define, which entity checks 

The AUTH_SESSION object contains the ID of an authorizing entity, so the
NSLP nodes on the path can choose the token from the authorizing entity
they trust.

Allowing multiple AUTH_SESSION objects is fine, but I'd suggest to
assign different IDs to each of them. As far as I know, none of
the other NSIS protocols allows multiple objects with the same ID.
This way, it's very easy to store them in arrays or hash maps in an
implementation.

In case only two different tokens should be supported, two IDs could be
assigned: One for the sender domain and one for the receiver domain. I'm
not sure if more than two tokens are realistic.

Cheers,
	Matthias

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 26 Oct 2006 13:45:20 +0200

Hi Matthias, Jukka, all,

A valid point to ask and I see the need for carrying multiple  
AUTH_SESSION objects within a single message.

> This way, it's very easy to store them in arrays or hash maps in an

I do not see the assignment of multiple NSLP object IDs for  
AUTH_SESSION objects as a good solution to the problem. The NSLP  
object ID identifies a type of object and there is only one of type  
AUTH_SESSION object. It is indeed possible to have multiple instance  
of one object type in a NSLP message. But until now there hasn't been  
any need for this. So it is not possible by default but design  
decision to be made. I.e. it could be allowed to included multiple  
instances of the AUTH_SESSION object within a single NATFW NSLP  
message. The entity ID in the object would then be used to figure out  
which object needs to be used by whom.
> not sure if more than two tokens are realistic.

The only point is on who is assigning these IDs, avoiding duplicated  
IDs for different entities.

Thanks

   Martin