Authorization for NSIS Signaling Layer Protocols
draft-ietf-nsis-nslp-auth-07

[Ballot discuss]
Please respond to the Gen-ART Review by Ben Campbell on 2010-08-31.
  At a minimum, please address these points:

  Section 3.2.7, 2nd para: "The creator of this attribute lists every
  NSLP object..."  Is there an order requirement? At least, the order
  in this list must match the order in the signature, right?

  Section 4.1.1, 2nd para: Is HMAC-MD5 still a reasonable choice for a
  single mandatory-to-implement algorithm?

  Section 6.4, 1st para: This paragraph seems to conflate authentication
  with authorization. Integrity protection provides authentication, from
  which one can apply authorization policy. But it's not authorization
  policy in itself.

  Section 7, 3rd para: This seems to conflict with 3.2.7 and 3.2.8,
  which only conditionally require AUTHENTICATION_DATA to be included.

[Ballot comment]
Updated #4 to be more specific.

1) Sec 3.2.7: MUST?

OLD:

rsv: reserved bits and must be set to 0 (zero) and ignored upon
  reception.

NEW:

rsv: reserved bits and MUST be set to 0 (zero) and ignored upon
  reception.

2) Sec 3.7, MUST?

OLD:

... they must be delivered
  via the GIST API and normalized to ...

NEW:

... they MUST be delivered
  via the GIST API and normalized to ...

3) Figure in Sec 4.3 only shows PGP_CERT.  Should it also show X509_V3_CERT?  Also shouldn't the other figures in the draft include "Figure #"?

4) Sec 4.4: Replace recommended with RECOMMENDED (x2)?

5) Sec 4.4: hash algorithm must be chosen vs hash algorithm MUST be chosen?

[Ballot discuss]
This is an updated DISCUSS.  I retained the original numbering scheme but removed the discuss positions that have been resolved via email.

3) Doesn't Sec 6.2.3 and 6.3.3 need bullets in the "verify message integrity" stage for hmac-signed?  It's the mandatory to implement mechanism - isn't it?

4) Please add something in the security considerations about considerations for:

4a) Symmetric Key: Keeping the symmetric key secret is central to preserving the security of the system.  Disclosure of the symmetric key can lead to

4b) Public Keys: Point to RFC 5280 for security considerations for X.509 certificate.  Point to RFC 4880 for PGP.

4c) For HMAC-signed, need to say something about keeping the shared key secret too.

[Ballot discuss]
This is a discuss-discuss.  I need further information before I can sort out which pieces of this are appropriate or
actionable.

As far as I can tell, this document applies the session policy element paradigm from RFC 3520 to nsis with two
extensions: a new X-type, NSLP_OBJECT_LIST, and a new AUTH_ENT_ID subtype HMAC_SIGNED.

I am having a very hard time sorting out the differences between HMAC_SIGNED and the various symmetric key
options carried over from 3520.  HMAC is of course a symmetric key authentication option, and Section 4.1.1
identifies HMAC-MD-128 as the mandatory to implement.  Section 3.2.1 explicitly notes that HMAC_SIGNED is
calculated over the NSLP objects in the NSLP_OBJECT_LIST, but my reading of the AUTHENTICATION_DATA attribute (3.2.8, "signs all data in the policy element up to the AUTHENTICATION DATA" and AUTHENTICATION
DATA "MUST be the last attribute in the list").

As I understand section 2, NSIS relies on a hop-by-hop security architecture although some things can be end-to-end.
Is the point here that we are layering end-to-end authorization on top of the hop-by-hop architecture?  The last
paragraph in section 2 seems to indicate that some authorization will be end-to-end and others hop-by-hop.
Which mechanisms apply in the different cases?

[Ballot comment]
1) Sec 3.2.7: MUST?

OLD:

rsv: reserved bits and must be set to 0 (zero) and ignored upon
  reception.

NEW:

rsv: reserved bits and MUST be set to 0 (zero) and ignored upon
  reception.

2) Sec 3.7, MUST?

OLD:

... they must be delivered
  via the GIST API and normalized to ...

NEW:

... they MUST be delivered
  via the GIST API and normalized to ...

3) Figure in Sec 4 only shows PGP_CERT

4) Sec 4.4: Replace recommended with RECOMMENDED (x2)?

5) Sec 4.4: hash algorithm must be chosen vs hash algorithm MUST be chosen?

[Ballot discuss]
1) This document is eerily similar to RFC 3520 (in some cases a direct copy).  I'm all for text reuse, but copying sections can introduce issues when trying to ensure that the text remains aligned (e.g., an errata is submitted against 3520 - it won't be reflected here).  Wouldn't it be best to just point to RFC 3520, except where you've changed things?

1a) Sections 3.2 (modulo 3.2.7): As far as I can tell, these sections define one authorizing entity identifier (sec 3.2.1), one source address (sec 3.2.3), one destination address (sec 3.2.4) not in RFC 3520.  The rest looks like a verbatim copy.

1b) Sec 4 (modulo 4.2 and 4.4) is pretty much the same as 3520.

2) Aren't the values for X-type, START_TIME, END_TIME already defined as well as all but one AUTH_ENT_ID, SOURCE_ADDR, and DEST_ADDR (http://www.iana.org/assignments/cops-parameters)?  Is this a new registry or just updating the existing one?

3) Doesn't Sec 6.2.3 and 6.3.3 need bullets in the "verify message integrity" stage for hmac-signed?  It's the mandatory to implement mechanism - isn't it?

4) Please add something in the security considerations about considerations for:

4a) Symmetric Key: Keeping the symmetric key secret is central to preserving the security of the system.  Disclosure of the symmetric key can lead to

4b) Public Keys: Point to RFC 5280 for security considerations for X.509 certificate.  Point to RFC 4880 for PGP.

4c) For HMAC-signed, need to say something about keeping the shared key secret too.

5) For the format of the SESSION_AUTH, couldn't you assign ranges for the type to achieve the same thing as the first four bits?  That way you could reuse the exact format from 3520?

[Ballot comment]
1) Sec 3.2.7: MUST?

OLD:

rsv: reserved bits and must be set to 0 (zero) and ignored upon
  reception.

NEW:

rsv: reserved bits and MUST be set to 0 (zero) and ignored upon
  reception.

3) Sec 3.7, MUST?

OLD:

... they must be delivered
  via the GIST API and normalized to ...

NEW:

... they MUST be delivered
  via the GIST API and normalized to ...

3) Sec 4.4: Replace recommended with RECOMMENDED (x2)?

4) Sec 4.4: hash algorithm must be chosen vs hash algorithm MUST be chosen?

[Ballot discuss]
1) This document is eerily similar to RFC 3520 (in some cases a direct copy).  I'm all for text reuse, but copying sections can introduce issues when trying to ensure that the text remains aligned (e.g., an errata is submitted against 3520 - it won't be reflected here).  Wouldn't it be best to just point to RFC 3520, except where you've changed things?

1a) Sections 3.2 (modulo 3.2.7): As far as I can tell, these sections define one authorizing entity identifier (sec 3.2.1), one source address (sec 3.2.3), one destination address (sec 3.2.4) not in RFC 3520.  The rest looks like a verbatim copy.

1b) Sec 4 (modulo 4.2 and 4.4) is pretty much the same as 3520.

2) Aren't the values for X-type, START_TIME, END_TIME already defined as well as all but one AUTH_ENT_ID, SOURCE_ADDR, and DEST_ADDR (http://www.iana.org/assignments/cops-parameters)?  Is this a new registry or just updating the existing one?

3) Doesn't Sec 6.2.3 and 6.3.3 need bullets in the "verify message integrity" stage for hmac-signed?  It's the mandatory to implement mechanism - isn't it?

4) Please add something in the security considerations about considerations for:

4a) Symmetric Key: Keeping the symmetric key secret is central to preserving the security of the system.  Disclosure of the symmetric key can lead to

4b) Public Keys: Point to RFC 5280 for security considerations for X.509 certificate.  Point to RFC 4880 for PGP.

4c) For HMAC-signed, need to say something about keeping the shared key secret too.

[Ballot comment]
1) Sections 3.2 (modulo 3.2.7): As far as I can tell, these sections define one authorizing entity identifier (sec 3.2.1), one source address (sec 3.2.3), one destination address (sec 3.2.4) not in RFC 3520.  The rest looks like a verbatim copy.  I'm all for text reuse, but copying sections can introduce issues when trying to ensure that the text remains aligned (e.g., an errata is submitted against 3520 - it won't be reflected here).

2) Sec 3.2.7: MUST?

OLD:

rsv: reserved bits and must be set to 0 (zero) and ignored upon
  reception.

NEW:

rsv: reserved bits and MUST be set to 0 (zero) and ignored upon
  reception.

3) Sec 3.7, MUST?

OLD:

... they must be delivered
  via the GIST API and normalized to ...

NEW:

... they MUST be delivered
  via the GIST API and normalized to ...

4) Sec 4 (modulo 4.2 and 4.4) is pretty much the same as 3520.  Can't you just have a section that says here's the new bits in addition to those in 3520?

5) Sec 4.4: Replace recommended with RECOMMENDED (x2)?

6) Sec 4.4: hash algorithm must be chosen vs hash algorithm MUST be chosen?

7) Aren't the values for X-type, START_TIME, END_TIME already defined as well as all but one AUTH_ENT_ID, SOURCE_ADDR, and DEST_ADDR (http://www.iana.org/assignments/cops-parameters)?  Is this a new registry or just updating the existing one?

8) Doesn't Sec 6.2.3 and 6.3.3 need bullets in the "verify message integrity" stage for hmac-signed?  It's the mandatory to implement mechanism - isn't it?

9) Please add something in the security considerations about considerations for

a) Symmetric Key: Keeping the symmetric key secret is central to preserving the security of the system.  Disclosure of the symmetric key can lead to

b) Public Keys: Point to RFC 5280 for security considerations for X.509 certificate.  Point to RFC 4880 for PGP.

c) For HMAC-signed, need to say something about keeping the shared key secret too.

[Ballot comment]
1) Sections 3.2 (modulo 3.2.7): As far as I can tell, these sections define one authorizing entity identifier (sec 3.2.1), one source address (sec 3.2.3), one destination address (sec 3.2.4) not in RFC 3520.  The rest looks like a verbatim copy.  I'm all for text reuse, but copying sections can introduce issues when trying to ensure that the text remains aligned (e.g., an errata is submitted against 3520 - it won't be reflected here).

2) Sec 3.2.7: MUST?

OLD:

rsv: reserved bits and must be set to 0 (zero) and ignored upon
  reception.

NEW:

rsv: reserved bits and MUST be set to 0 (zero) and ignored upon
  reception.

3) Sec 3.7, MUST?

OLD:

... they must be delivered
  via the GIST API and normalized to ...

NEW:

... they MUST be delivered
  via the GIST API and normalized to ...

3) Sec 4 (modulo 4.2 and 4.4) is pretty much the same as 3520.  Can't you just have a section that says here's the new bits in addition to those in 3520?

4) Sec 4.4: Replace recommended with RECOMMENDED (x2)?

5) Sec 4.4: hash algorithm must be chosen vs hash algorithm MUST be chosen?

6) Aren't the values for X-type, START_TIME, END_TIME already defined as well as all but one AUTH_ENT_ID, SOURCE_ADDR, and DEST_ADDR (http://www.iana.org/assignments/cops-parameters)?  Is this a new registry or just updating the existing one?

7) Doesn't Sec 6.2.3 and 6.3.3 need bullets in the "verify message integrity" stage for hmac-signed?  It's the mandatory to implement mechanism - isn't it?

8) Please add something in the security considerations about considerations for

a) Symmetric Key: Keeping the symmetric key secret is central to preserving the security of the system.  Disclosure of the symmetric key can lead to

b) Public Keys: Point to RFC 5280 for security considerations for X.509 certificate.  Point to RFC 4880 for PGP.

c) For HMAC-signed, need to say something about keeping the shared key secret too.

[Ballot comment]
1) Sections 3.2 (modulo 3.2.7): As far as I can tell, these sections define one authorizing entity identifier (sec 3.2.1), one source address (sec 3.2.3), one destination address (sec 3.2.4) not in RFC 3520.  The rest looks like a verbatim copy.  I'm all for text reuse, but copying sections can introduce issues when trying to ensure that the text remains aligned (e.g., an errata is submitted against 3520 - it won't be reflected here).

2) Sec 3.2.7: MUST?

OLD:

rsv: reserved bits and must be set to 0 (zero) and ignored upon
  reception.

NEW:

rsv: reserved bits and MUST be set to 0 (zero) and ignored upon
  reception.

3) Sec 3.7, MUST?

OLD:

... they must be delivered
  via the GIST API and normalized to ...

NEW:

... they MUST be delivered
  via the GIST API and normalized to ...

3) Sec 4 (modulo 4.2 and 4.4) is pretty much the same as 3520.  Can't you just have a section that says here's the new bits in addition to those in 3520?

4) Sec 4.4: Replace recommended with RECOMMENDED (x2)?

5) Sec 4.4: hash algorithm must be chosen vs hash algorithm MUST be chosen?

6) Aren't the values for X-type, START_TIME, END_TIME already defined as well as all but one AUTH_ENT_ID, SOURCE_ADDR, and DEST_ADDR (http://www.iana.org/assignments/cops-parameters)?  Is this a new registry or just updating the existing one?

[Ballot comment]
1) Sections 3.2 (modulo 3.2.7): As far as I can tell, these sections define one authorizing entity identifier (sec 3.2.1), one source address (sec 3.2.3), one destination address (sec 3.2.4) not in RFC 3520.  The rest looks like a verbatim copy.  I'm all for text reuse, but copying sections can introduce issues when trying to ensure that the text remains aligned (e.g., an errata is submitted against 3520 - it won't be reflected here).

2) Sec 3.2.7: MUST?

OLD:

rsv: reserved bits and must be set to 0 (zero) and ignored upon
  reception.

NEW:

rsv: reserved bits and MUST be set to 0 (zero) and ignored upon
  reception.

3) Sec 4 (modulo 4.2 and 4.4) is pretty much the same as 3520.  Can't you just have a section that says here's the new bits in addition to those in 3520?

4) Sec 4.4: Replace recommended with RECOMMENDED (x2)?

5) Sec 4.4: hash algorithm must be chosen vs hash algorithm MUST be chosen?

6) Aren't the values for X-type, START_TIME, END_TIME already defined as well as all but one AUTH_ENT_ID, SOURCE_ADDR, and DEST_ADDR (http://www.iana.org/assignments/cops-parameters)?  Is this a new registry or just updating the existing one?

[Ballot discuss]
Please respond to the Gen-ART Review by Ben Campbell on 2010-08-31.
  At a minimum, please address these points:

  Section 3.2.7, 2nd para: "The creator of this attribute lists every
  NSLP object..."  Is there an order requirement? At least, the order
  in this list must match the order in the signature, right?

  Section 4.1.1, 2nd para: Is HMAC-MD5 still a reasonable choice for a
  single mandatory-to-implement algorithm?

  Section 6.4, 1st para: This paragraph seems to conflate authentication
  with authorization. Integrity protection provides authentication, from
  which one can apply authorization policy. But it's not authorization
  policy in itself.

  Section 7, 3rd para: This seems to conflict with 3.2.7 and 3.2.8,
  which only conditionally require AUTHENTICATION_DATA to be included.

[Ballot comment]
1) Sections 3.2 (modulo 3.2.7): As far as I can tell, these sections define one authorizing entity identifier (sec 3.2.1), one source address (sec 3.2.3), one destination address (sec 3.2.4) not in RFC 3520.  The rest looks like a verbatim copy.  I'm all for text reuse, but copying sections can introduce issues when trying to ensure that the text remains aligned (e.g., an errata is submitted against 3520 - it won't be reflected here).

2) Sec 4 (modulo 4.2 and 4.4) is pretty much the same as 3520.  Can't you just have a section that says here's the new bits in addition to those in 3520?

3) Sec 4.4: Replace recommended with RECOMMENDED (x2)?

4) Sec 4.4: hash algorithm must be chosen vs hash algorithm MUST be chosen?

5) Aren't the values for X-type, START_TIME, END_TIME already defined as well as all but one AUTH_ENT_ID, SOURCE_ADDR, and DEST_ADDR (http://www.iana.org/assignments/cops-parameters)?  Is this a new registry or just updating the existing one?

IANA comments:

Upon approval of this document, IANA understands that there are seven
IANA Actions that need to be completed.

First, in the NSLP Message Objects subregistry of the NSIS Signaling
Layer Protocol (NSLP) Parameters located at:

http://www.iana.org/assignments/nslp-parameters/nslp-parameters.xml

a new value is to be added to the subregistry as follows:

Value Description Reference
----- --------------------------------------- ---------
tbd1 SESSION_AUTH_OBJECT RFC-to-be

Second, a new subregistry of the NSIS Signaling Layer Protocol (NSLP)
Parameters located at:

http://www.iana.org/assignments/nslp-parameters/nslp-parameters.xml

is to be created. The new "SESSION_AUTH Object X-Type" subregistry will
have the following registration procedures:

Range Registration Procedures
----- ---------------------------
0-127 Specification Required
128-255 Private or Experimental Use

The new "SESSION_AUTH X-Type" subregistry will have the following
initial values:

X-Type Description
-------- -------------------
0 Reserved
1 AUTH_ENT_ID
2 SESSION_ID
3 SOURCE_ADDR
4 DEST_ADDR
5 START_TIME
6 END_TIME
7 NSLP_OBJECT_LIST
8 AUTHENTICATION_DATA
9-127 Unassigned
128-255 Reserved

Third, a new subregistry of the NSIS Signaling Layer Protocol (NSLP)
Parameters located at:

http://www.iana.org/assignments/nslp-parameters/nslp-parameters.xml

is to be created. The new "AUTH_ENT_ID (X-Type 1) SubType values"
subregistry will have the following registration procedures:

Range Registration Procedures
---------- -----------------------
0-127 Specification Required
128-255 Private or Experimental Use

The new "AUTH_ENT_ID (X-Type 1) SubType values" subregistry will have
the following initial values:

Registry:
SubType Description
-------- -------------
0 Reserved
1 IPV4_ADDRESS
2 IPV6_ADDRESS
3 FQDN
4 ASCII_DN
5 UNICODE_DN
6 URI
7 KRB_PRINCIPAL
8 X509_V3_CERT
9 PGP_CERT
10 HMAC_SIGNED
11-127 Unassigned
128-255 Reserved

Fourth, a new subregistry of the NSIS Signaling Layer Protocol (NSLP)
Parameters located at:

http://www.iana.org/assignments/nslp-parameters/nslp-parameters.xml

is to be created. The new "SOURCE_ADDR (X-Type 3) SubType values"
subregistry will have the following registration procedures:

Range Registration Procedures
---------- -----------------------
0-127 Specification Required
128-255 Private or Experimental Use

The new "SOURCE_ADDR (X-Type 3) SubType values" subregistry will have
the following initial values:

Registry:
SubType Description
-------- -------------
0 Reserved
1 IPV4_ADDRESS
2 IPV6_ADDRESS
3 UDP_PORT_LIST
4 TCP_PORT_LIST
5 SPI
6-127 Unassigned
128-255 Reserved

Fifth, a new subregistry of the NSIS Signaling Layer Protocol (NSLP)
Parameters located at:

http://www.iana.org/assignments/nslp-parameters/nslp-parameters.xml

is to be created. The new "DEST_ADDR (X-Type 4) SubType values"
subregistry will have the following registration procedures:

Range Registration Procedures
---------- ------------------------
0-127 Specification Required
128-255 Private or Experimental Use

The new "DEST_ADDR (X-Type 4) SubType values" subregistry will have the
following initial values:

Registry:
SubType Description
-------- -------------
0 Reserved
1 IPV4_ADDRESS
2 IPV6_ADDRESS
3 UDP_PORT_LIST
4 TCP_PORT_LIST
5 SPI
6-127 Unassigned
128-255 Reserved

Sixth, a new subregistry of the NSIS Signaling Layer Protocol (NSLP)
Parameters located at:

http://www.iana.org/assignments/nslp-parameters/nslp-parameters.xml

is to be created. The new "START_TIME (X-Type 5) SubType values"
subregistry will have the following registration procedures:

Range Registration Procedures
---------- -----------------------
0-127 Specification Required
128-255 Private or Experimental Use

The new "START_TIME (X-Type 5) SubType values" subregistry will have the
following initial values:

Registry:
SubType Description
-------- -------------
0 Reserved
1 NTP_TIMESTAMP
2-127 Unassigned
128-255 Reserved

Seventh, a new subregistry of the NSIS Signaling Layer Protocol (NSLP)
Parameters located at:

http://www.iana.org/assignments/nslp-parameters/nslp-parameters.xml

is to be created. The new "END_TIME (X-Type 6) SubType values"
subregistry will have the following registration procedures:

Range Registration Procedures
---------- -----------------------
0-127 Specification Required
128-255 Private or Experimental Use

The new "END_TIME (X-Type 6) SubType values" subregistry will have the
following initial values:

Registry:
SubType Description
-------- -------------
0 Reserved
1 NTP_TIMESTAMP
2-127 Unassigned
128-255 Reserved

IANA understands that there are no SubType value subregistries for
X-Type 2. X-Type 7 and X-Type 8. Further, IANA understands that the
seven actions above are all the IANA actions required upon approval of
the document.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Martin Stiemerling (martin.stiemerling@neclab.eu) is the
document shepherd. I have reviewed the document and it is
read for taking the next steps towards publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

It has been review by the NSIS WG. There has been a WGLC
with good comments and no controversial issues.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

It may be good to get a review from the security community
as the document is mainly about security.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No issues.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is strong WG consensus behind this document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Yes, it does.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

Yes, it does.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

Yes, it does.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

There are no such sections in this document.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

Signaling layer protocols specified within the NSIS framework may
rely on the GIST (General Internet Signaling Transport) protocol to
handle authorization. Still, the signaling layer protocol above GIST
itself may require separate authorization to be performed when a node
receives a request for a certain kind of service or resources. This
draft presents a generic model and object formats for session
authorization within the NSIS Signaling Layer Protocols. The goal of
session authorization is to allow the exchange of information between
network elements in order to authorize the use of resources for a
service and to coordinate actions between the signaling and transport
planes.

Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

This draft is an outcome of the NSIS WG.

Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

There is an implementation made by University of Karlsruhe
(Roland Bless,
https://projekte.tm.uni-karlsruhe.de/trac/NSIS/wiki/SessionAuthorizationObject)