Glen Zorn wrote:
> Alan DeKok wrote:
> ... It would have been preferable ...
> To which I reply:
>
> So it seems that what you _really_ meant was "... well, screw 'em."
I think there is a miscommunication here.
Alan DeKok.
___
Ietf mailing list
Glen Zorn wrote:
> But none of the Attributes mentioned in Appendix B have anything to do with
> RADIUS security as I understand it. Can you explain?
From the document:
Appendix B includes a
listing of complex attributes used within [RFC2865], [RFC2868],
[RFC2869], [RFC3162], [RFC4818
...
> Following on Dan's review, I've reviewed the document for agreement
> with the RADIUS design guidelines document [1]
>
>
> Both the PKM-SS-Cert and PKM-CA-Cert attributes provide 'ad-hoc'
> extension of the RADIUS attribute size, much like the EAP-Message
> attribute.
Actually, the m
Alan DeKok wrote:
Both the PKM-SS-Cert and PKM-CA-Cert attributes provide 'ad-hoc'
extension of the RADIUS attribute size, much like the EAP-Message
attribute. It would have been preferable to follow the extended
attribute format [2]. This provides a standardized way of carrying data
larger th
Alan DeKok [mailto:al...@deployingradius.com] writes:
> Glen Zorn wrote:
> > But none of the Attributes mentioned in Appendix B have anything to
> do with
> > RADIUS security as I understand it. Can you explain?
>
> From the document:
>
>Appendix B includes a
>listing of complex attri
d.b.nel...@comcast.net wrote:
> > Yeah. I've always been a bit uncomfortable with the "security
> > functionality" escape clause in the RADIUS Design Guidelines draft.
> > Lots of things can reasonably be claimed to be "security related". I
> > would have preferred the exception to be crafted
Sorry for the late response -- my laptop was stolen in Stockholm & I'm just
getting back to normal :-(
> If we are to dismiss the Design Guidelines as a "personal preference" how
are they to be taken seriously?
They shouldn't be taken _too_ seriously.
> I understand that following someone else
d.b.nel...@comcast.net wrote:
> Yeah. I've always been a bit uncomfortable with the "security
> functionality" escape clause in the RADIUS Design Guidelines draft.
> Lots of things can reasonably be claimed to be "security related". I
> would have preferred the exception to be crafted a bit narr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> "Alan" == Alan DeKok writes:
Alan> Both the PKM-SS-Cert and PKM-CA-Cert attributes provide
Alan> 'ad-hoc' extension of the RADIUS attribute size, much like the
Alan> EAP-Message attribute. It would have been preferable to
Back
Glen Zorn writes...
> > As a result, the introduction of new complex data types within
> > RADIUS attribute specifications SHOULD be avoided, except
> > in the case of complex attributes involving authentication or
> > security functionality.
>
> All of the attributes are security rel
Romascanu, Dan (Dan) wrote:
> I have reviewed as shepherding AD draft-zorn-radius-pkmv1-04.txt
Following on Dan's review, I've reviewed the document for agreement
with the RADIUS design guidelines document [1]
Both the PKM-SS-Cert and PKM-CA-Cert attributes provide 'ad-hoc'
extension of the
Glen Zorn wrote:
> No. There _are_ implementations as I rather clearly stated at the meeting
> in SF, using the Experimental attribute space.
So the implementations have to be updated to use the IANA code points,
independent of them possibly using the extended attributes format.
> Given that t
Alan DeKok [mailto:al...@deployingradius.com] writes:
> Romascanu, Dan (Dan) wrote:
> > I have reviewed as shepherding AD draft-zorn-radius-pkmv1-04.txt
>
> Following on Dan's review, I've reviewed the document for agreement
> with the RADIUS design guidelines document [1]
>
>
> Both the PK
13 matches
Mail list logo
