Extension of NSLP Session Authorization (draft-manner-nsis-nslp-auth)

Hi,

just a few quick comments for extending the approach described in the
I-D draft-manner-nsis-nslp-auth,
http://tools.ietf.org/id/draft-manner-nsis-nslp-auth, which I
find very important for NSIS.
This draft proposes an object that can be embedded into NSLP
messages as an authorization token. User-based session authorization
is important for security-sensitive NAT/FW applications as well as
for QoS for secure accounting. However, we find the presented approach
a little bit too limited, since it mainly follows RFC3520.
The coupling between the authorization object and the NSLP
message is too weak in our opinion (basically only achieved by
the IP signaling source address).

Our idea is now, to actually "sign" NSLP messages by including
NSLP objects into the MAC. Thus, NSLP messages would be integrity
protected by an HMAC for example. So we could add a list of signed
NSLP object types, e.g.
                                       X-Type
      +--------------+--------------+--------------+--------------+
      | Length                      | NSLP_OBJ_LIST| SubType=0    |
      +--------------+--------------+--------------+--------------+
      |Number of NSLP signed objects|rsv |NSLP Signed Object (1)  |
      +--------------+--------------+--------------+--------------+
      |rsv |NSLP Signed Object (n)  |    (padding if required)    |
      +--------------+--------------+--------------+--------------+

So this list simply contains the object types of the NSLP message
that the MAC includes. Since NSLP object types have a common registry,
this can be used for every NSLP.
Furthermore, we propose that we try to consider "crypto agility" a
little bit, i.e., we want to include an identifier for the hash
algorithm etc.

Would this make sense to include such functionality into the nslp
session auth object?

Regards,
 Roland