Re: draft-zorn-radius-pkmv1-05.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Yes, the changes below look good to me.

Thanks,
Donald

On Wed, Aug 26, 2009 at 9:40 PM, Glen Zorn<gwz@xxxxxxxxxxx> wrote:
> Donald Eastlake [mailto:d3e3e3@xxxxxxxxx] writes:
>
> ...
>
>> >> The wording in Sections 3.1 and 3.2 see to almost be designed to
>> allow
>> >> the possibility of the multiple *-Cert Attributes carrying a
>> >> certificate to appear in more than one Access-Request message. But I
>> >> would assume that's not meaningful and/or was not intended to allow
>> >> that.
>> >
>> > There is no way to do such a thing in standard RADIUS.
>>
>> That's what I thought and why I was puzzled as to why there was a more
>> complex wording that appears to permit this. I suppose it is just the
>> way the words struck me at the time I read them. But I would, instead
>> of
>>
>>           If multiple PKM-SS-Cert
>>       Attributes are contained within an Access-Request packet, they
>>       MUST be in order and MUST be consecutive attributes in the
>> packet.
>>
>> have said
>>
>>       These multiple PKM-SS-Cert Attributes MUST appear consecutively
>>       and in order within an Access-Request packet.
>>
>> and similarly for PKM-CA-Cert.
>
> OK.
>
> ...
>
>> >> This whole table needs to be carefully checked, the
>> >> inconsistencies resolved, and it should be clear if literal binary
>> >> attributes or some sort of logical aggregate attributes (in the case
>> >> of the "Cert" attributes at least), is being counted.
>> >
>> > I can add notes to the table regarding the "logical" vs. "physical"
>> nature
>> > of the PKM-*-Cert Attributes, as well as a key to the meaning of
>> "0+", etc.
>> > Is that OK?
>>
>> Yes.
>
> You were right, the entries for the PKM*Cert Attributes should have been 0+
> instead of 0-1.  The Table of Attributes now looks like this:
>
>   The following table provides a guide to which attributes may be found
>   in which kinds of packets, and in what quantity.
>
>     Request Accept Reject Challenge Acct-Req  #   Attribute
>     0+      0      0      0         0        TBD1 PKM-SS-Cert [Note 1]
>     0+      0      0      0         0        TBD2 PKM-CA-Cert [Note 2]
>     0       0-1    0      0         0        TBD3 PKM-Config-Settings
>     0-1     0      0      0         0        TBD4 PKM-Cryptosuite-List
>     0-1     0      0      0         0        TBD5 PKM-SAID
>     0       0+     0      0         0        TBD6 PKM-SA-Descriptor
>     0       0-1    0      0         0        TBD7 PKM-Auth-Key
>
>   [Note 1]
>      No more than one Subscriber Station Certificate may be transferred
>      in an Access-Request packet.
>
>   [Note 1]
>      No more than one CA Certificate may be transferred in an Access-
>      Request packet.
>
>   The following table defines the meaning of the above table entries.
>
>   0   This attribute MUST NOT be present in packet
>   0+  Zero or more instances of this attribute MAY be present in packet
>   0-1 Zero or one instance of this attribute MAY be present in packet
>   1   Exactly one instance of this attribute MUST be present in packet
>
> Is that OK?
>
> ...
>
>
>
_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]