Re: [NSIS] AD review: draft-ietf-nsis-nslp-auth-02.txt

[Roland Bless <[e-mail]>]

Hi Lars,

on 11.06.2010 15:15, Lars Eggert wrote:
> Summary: Not ready, revision needed, see below.
> 
> Meta question: This document is very complex. Do we have any real

I guess that this problem is caused by the fact that
the document heavily bases on the
Session Authorization Policy Element for RSVP (RFC 3520).

> experience with coupling NSLP authorization with X.500, Kerberos,
> PGP, etc.? Do any of the experimental implementations use this to

So the question is: is RFC 3520 really used anywhere in existing
RSVP deployments? If not, probably we can dismiss most of the
RFC 3520 legacy stuff and aim for something simpler (that
is actually my preference), since there is no reason for code
reuse.

> authorize QoS NSLP or NATFW NSLP actions?

We actually implemented the HMAC_SIGNED part and the full
PDU structure including all objects. Currently, however,
we have no interworking with other backend solutions like Kerberos
or AAA infrastructure, though a master student will try to take
care of this soon.

Thanks for the thorough review, I'll take care of the obvious nits and
edits asap. I'll reply to some of your comments here.

> Section 2., paragraph 3:
>> The so far specified basic security architecture for NSIS is based
>> on
> 
> s/so far specified//   (there won't be any other, no?)

right.

> Section 3.2., paragraph 5:
>> Session authorization attribute type (X-Type) field is one octet. 
>> IANA acts as a registry for X-Types as described in Section 7, IANA
>> Considerations.  Initially, the registry contains the following
>> X-Types:
> 
> The IANA considerations are in Section 8. And that section doesn't 
> define this new registry.

Good catch, probably caused by a copy & paste error with hard referecens
in an earlier version.


> Section 1., paragraph 0:
>> 1.  1 NTP_TIMESTAMP NTP Timestamp Format as defined in RFC 1305.
> 
> RFC1305 needs to be a normative reference.

OK.

> Section 3.2.6., paragraph 15:
>> padding: padding is required if the number of NSLP objects is
>> even. The padding field MUST be 16 bit set to 0.
> 
> Ambiguous. You mean that the padding is REQUIRED when even and that
> it MUST NOT be added when odd.

OK

> Section 6.2., paragraph 0:
>> 6.2.  Processing within the QoS NSLP 

> Does this mean that this document updates draft-ietf-nsis-qos-nslp?

Good question. I don't think so, since you perform additional
actions when implementing  draft-ietf-nsis-nslp-auth, so it
affects the implementation behavior, but not the basic
QoS NSLP protocol behavior.

> Section 6.3., paragraph 0:
>> 6.3.  Processing with the NAT/FW NSLP
> 
> Does this mean that this document updates
> draft-ietf-nsis-nslp-natfw?

See above.

> Section 10.2., paragraph 4:
>> [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter,
>> "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, 
>> August 1998.
> 
> Obsolete informational reference (is this intentional?): RFC 2396 
> (Obsoleted by RFC 3986)
> 
> 
> Section 10.2., paragraph 7:
>> [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)", RFC
>> 3852, July 2004.
> 
> Obsolete informational reference (is this intentional?): RFC 3852 
> (Obsoleted by RFC 5652)

Will double check.

Thanks,
 Roland