-----Original Message-----
From: Sam Hartman [mailto:hartmans-ietf(_at_)mit(_dot_)edu]
Sent: 29 August 2011 14:58
To: Richards, Gareth
Cc: Black, David; hartmans-ietf(_at_)mit(_dot_)edu;
gen-art(_at_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org; ietf-krb-wg(_at_)lists(_dot_)anl(_dot_)gov;
stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie
Subject: Re: Gen-ART review of draft-ietf-krb-wg-otp-preauth-18
<gareth(_dot_)richards(_at_)rsa(_dot_)com> writes:
>> > Why should we require that alg-ids be registered URIs?
>>
>> That's not my concern - the existing first paragraph of the IANA
>> considerations section in the draft requires IANA registration
>> (or at least tries to) by pointing to the PSKC registry. My
>> concern is that if this is going to be done, it needs to be done
>> right (duh!), and the current text is insufficient. Please take
>> the issue of whether to use IANA for this purpose up with Gareth
>> and the WG.
>>
>> > I have no problem with the IETF registering its algorithms
>> there, or us > encouraging people to register them there, but
>> it's a URI. What purpose > is served by forcing registration?
>>
>> Hmm - more than one URI for the same algorithm might cause
>> interoperability problems.
>>
g>Some form of identifier will be required for the otp-algID in the PA-
OTP-CHALLENGE and the PA-OTP-REQUEST and from what I remember about
when this was first discussed, it was agreed that it would make sense
to use the registry of identifiers already being established for PSKC
rather than produce a duplicate one. My assumption was that a registry
would be required to ensure that the URIs were unique.
I don't really care so just fix the current text to resolve David's
concern. My point was simply that whatever spec tells you how to use
some algorithm with Kerberos can provide a unique URI and I'm
unconvinced that it matters where that URI is drawn so long as everyone
agrees on the URI. Having a registry for everything the IETF does is
fine; reusing an existing registry is better. Constraining what
non-IETF people do seems kind of silly but they will not listen to us
anyway, so no harm is done.
How about the following text? I am not sure whether to make these SHOULDs
rather than MUSTs to allow the option of other algorithm identifiers to be used.
a) Section 4.1:
otp-algID
Use of this field is OPTIONAL, but MAY be used by the KDC to
identify the algorithm to use when generating the OTP. URIs
used in this section SHOULD be obtained from the PSKC algorithm
registry [RFC6030].
b) Section 4.2
otp-algID
This field MAY be used by the client to send the identifier of the
OTP algorithm used, as reported by the OTP token. Use of this
element is OPTIONAL but it MAY be used by the client to simplify
the OTP calculations carried out by the KDC. It is RECOMMENDED
that the KDC act upon this value if it is present in the request
and it is capable of using it in the generation of the OTP value.
URIs used in this section SHOULD be obtained from the PSKC algorithm
registry [RFC6030].
c) Section 5
The OTP algorithm identifiers used as otp-algID values in
the PA-OTP-CHALLENGE described in section 4.1 and the PA-OTP-REQUEST
described in section 4.2 SHOULD be registered in the PSKC algorithm
registry [RFC6030].
--Gareth
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf