Subject: [NSIS] NSLP AUTH Questions

From: "David Palma" <[email-masked]>
Date: Fri, 2 Feb 2007 22:40:15 -0000

Hi all,

I'm from the University of Coimbra and I've been working on QoS NSLP and
recently on the NSLP AUTH extension objects to allow external authorization
on QoS NSLP.

Regarding the AUTH draft I have some questions about the parsing of the
proposed objects. Is this parsing done inside QoS NSLP or, like QSPEC with
RMF, done in an Authorization model? Are the AUTH objects opaque like the
QSPEC?

Another question is concerns the length of the Authorizing Entity Identifier
(page 9) object, where it says: "...Length of the attribute, which MUST be >
4". If the octet string could be an IPv4 address, shouldn't we read "...MUST
be >= 4"?

Another issue is on the length of Source Address object, where the octet
string could be a 16 bit port and consequently the length should be >= 2.

Can anybody help me with these questions?

Thank you in advance,
David Palma

-- 

Checked by AVG Free Edition.
Version: 7.1.411 / Virus Database: 268.17.19/663 - Release Date: 01-02-2007

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

---

From: Roland Bless <[email-masked]>
Date: Tue, 06 Feb 2007 10:56:13 +0100

Hi David,

> RMF, done in an Authorization model? Are the AUTH objects opaque like the

Yes and no.
We've considered the AUTH session object lately for its use in NAT/FW
traversal. What you want to do is basically the following:
- When a message arrives that contains an AUTH_Session object
  you want to verify the MAC in the AUTHENTICATION_DATA of the
  AUTH_Session object. This can be done separately and you want to
  use the same code in NAT/FW or QoS NSLP applications for that
  (i.e., this may happen outside the QoS NSLP code)
- After verifying the integrity of the AUTH_SESSION object you
  should compare some of the Session authorization attributes
  with other parts of the QoS NSLP message so that the
  AUTH_SESSION object is related to the actual QoS NSLP message.
  This will usually happen in the QoS NSLP code.
- In case that any verification above fails, QoS NSLP should
  simply discard the message and not process it any further.

> 4". If the octet string could be an IPv4 address, shouldn't we read "...MUST

At beginning of sec. 3.2 (p. 7) the Length description says that
it includes all octects of the attribute (except padding bytes),
and the attribute header is already 4 octets long.
If it contains an IPv4 address, it should be set to 8.

> string could be a 16 bit port and consequently the length should be >= 2.

Length is always >= 4 since it also includes the attribute header.
For a port number the attribute length should be set to 6.

> Can anybody help me with these questions?

Hope it helped.
 Roland