The KINK protocol (Kerberized IPsec) is now in its second IETF-wide Last
Call (the last was in 2002). Participants in this WG are encouraged to review the document and send in their comments. In addition, we have received a request to allocate two key usage numbers for KINK, in accordance with the requirements of RFC4120 section 9. Derek Atkins, chair of KINK, has forwarded to me the following description of what the numbers will be used for, taken from the KINK document: > 8. Key Usage Numbers for Kerberos Key Derivation > > Kerberos encrypt/decrypt functions and get_mic/verify_mic functions > require "key usage numbers". They are used to generate specific keys > for cryptographic operations so that different keys are used for > different purposes/objects. KINK uses two usage numbers listed > below. > > Purpose Usage number > ------- ------------ > KINK_ENCRYPT (for encryption) XXX -- TBA by rfc1510ter > Cksum (for checksum) XXX -- TBA by rfc1510ter If there are any comments or objections to assigning numbers for these key usages, please raise them on this list sometime in the next two weeks. If there are none by the time the IETF Last Call on KINK expires on Dec 12, 2005, I will ask Tom to select numbers and update the registry. -- Jeff ---------- Forwarded Message ---------- Date: Monday, November 28, 2005 01:42:59 PM -0500 From: The IESG <[hidden email]> To: IETF-Announce <[hidden email]> Subject: Last Call: 'Kerberized Internet Negotiation of Keys (KINK)' to Proposed Standard The IESG has received a request from the Kerberized Internet Negotiation of Keys WG to consider the following document: - 'Kerberized Internet Negotiation of Keys (KINK) ' <draft-ietf-kink-kink-10.txt> as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the [hidden email] or [hidden email] mailing lists by 2005-12-12. This draft was before the IETF in December of 2002 requesting last call comments. The protocol has changed to address IESG comments and because of evolution of Kerberos and IPsec in the following years. This second last call requests comments on the changes introduced in the protocol since 2002. Even given this long delaythere is still active interest in the work and in implementations of Kink. We would like to thank the Kink working group for their perseverance and apologize for the length of the delay. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-kink-kink-10.txt _______________________________________________ IETF-Announce mailing list [hidden email] https://www1.ietf.org/mailman/listinfo/ietf-announce ---------- End Forwarded Message ---------- |
Comments:
- Rekeying " 3.6. Rekeying Security Associations KINK requires the initiator of an SA to be responsible for rekeying the SA. ... " First, "requires" isn't proper RFC2119 terminology, and proper RFC2119 terminology in this regard is missing in that section. This would be fine, except that... ...second, since KINK allows for user-to-user Kerberos V exchanges I see no reason that responders couldn't, if they wanted to, act as initiators, so there's a question, I think, as to whether responders are simply not allowed to do that or merely expected to not do that. Or did I miss something else? Third, even if responders typically could not act as initiators (say, for implementation-specific issues), one might still want some notification that an SA has expired and traffic needs it to be rekeyed. Looking at the minutes from IETF62 I see that there was concern about having servers do the u2u dance, but when re-keying the server knows that it's had an SA with a particular peer and so I think the DoS concern goes away. - Section 5.3 limits the IDs that can be used with KINK to address/subnet/address range IDs. I think this is too limited, it seems likely to make KINK very difficult to use. I'd rather that a new ID type be defined that corresponds to Kerberos V principal names and/or that ID_FQDN and ID_RFC822_ADDR be allowed and a simple algorithm be recommended for matching principals and such IDs. In any case, much too little is said about IDs, and while what is said may be appropriate for a doc defining a KE protocol, unless a profile doc is to follow it that specifies such details... how is one to use this KE? Local/distributed configuration of principal<->IDs seems hard to deal with and prone to usability and/or interop problems, if not even to security problems (e.g., using DNS, not DNSSEC to map host principals to IP addresses to match to asserted IDs). Perhaps there should be a new principal name type hint for IP address based names. That would push some complexity from implementation to host administration, while creating a separate problem (how to determine the realm name of a given address), but it seems possibly worthwhile. - Section 4.2.4. How does cross-realm user-to-user work? Also, this doesn't make sense: " ... When the requested principal is "principal@REALM", ... " Isn't "principal@REALM" pretty much the only form that the requested principal name can take? Or are there other forms? Where are those described? - Section 4.2.4. How are the values of PrincName constructed? Are they DER encodings of SEQUENCE { pname PrincipalName, realm, RealmName}? Or are they an "unparsed" representation of principal names following rules similar to those listed in RFC4121? This is very simply dealt with by saying that the contents of PrincName is given by section 2.1.3 of RFC1964, but without the GSS-API exported name token header. - Key derivation. IKEv2 has different orders for the concatenation of the prf input data than KINK does. You might want to double check with a cryptographer that KINK is doing the right thing here (particularly in light of the NIST KDF work). - Sub-session key generation. Section 3.2.1 says that "... KINK takes advantage of the fact that the KDC provides a reliable source of randomness which is used in key derivation." But there's no prescribed mechanism by which Kerberos V clients are to include KDC-provided entropy into the sub-session key generation, nor is there any text saying that clients MAY/SHOULD/MUST do this in some, presumably, implementation dependent manner. RFC4120 does not, I think, rescue KINK here either, for it only says that "[if] the client selects a sub-session key, care must be taken to ensure the randomness of the selected sub-session key." I think it's better that KINK say that clients which do not have local, reliable sources of entropy SHOULD make use of KDC-provided entropy (in the form of ticket session keys and/or KDC-REP enc part nonces). Thanks, Nico -- |
>>>>> "Nicolas" == Nicolas Williams <[hidden email]> writes:
Nicolas> - Section 5.3 limits the IDs that can be used with KINK Nicolas> to address/subnet/address range IDs. I think this is too Nicolas> limited, it seems likely to make KINK very difficult to Nicolas> use. Nicolas> I'd rather that a new ID type be defined that Nicolas> corresponds to Kerberos V principal names and/or that Nicolas> ID_FQDN and ID_RFC822_ADDR be allowed and a simple Nicolas> algorithm be recommended for matching principals and such Nicolas> IDs. Nico, these are phase 2 IDs. I.E. they describe the SA, not the parties involved. I'm afraid you are living in an IKEV2 world where terminology makes sense. |
In reply to this post by Nicolas Williams
--On Tuesday, November 29, 2005 12:41:38 -0600 Nicolas Williams <[hidden email]> wrote: > - Sub-session key generation. > > Section 3.2.1 says that "... KINK takes advantage of the fact that > the KDC provides a reliable source of randomness which is used in key > derivation." But there's no prescribed mechanism by which Kerberos V > clients are to include KDC-provided entropy into the sub-session key > generation, nor is there any text saying that clients MAY/SHOULD/MUST > do this in some, presumably, implementation dependent manner. kink actually proscribes the use of sub-session keys: 4 KINK Message Format[....] o Cksum (variable) -- Kerberos keyed checksum over the entire message excluding the Cksum field itself.[...] The key used MUST be the session key in the ticket. 7 ISAKMP Key Derivation [....] o SKEYID_d is the session key in the Kerberos service ticket from the AP-REQ. Note that subkeys are not used in KINK and MUST be ignored if received. This issue has been discussed in the past (multiple times even), and bringing it up again will probably not result in anything other than wasted time. I did notice that section 4.2.7 KINK_ENCRYPT does not specify what key is used, only that it "is encrypted using the encryption algorithm specified by the etype of the session key" |
On Tue, Nov 29, 2005 at 03:57:40PM -0500, Chaskiel M Grundman wrote:
> --On Tuesday, November 29, 2005 12:41:38 -0600 Nicolas Williams > <[hidden email]> wrote: > > > - Sub-session key generation. > > [...] > kink actually proscribes the use of sub-session keys: > > 4 KINK Message Format[....] > o Cksum (variable) -- Kerberos keyed checksum over the entire > message excluding the Cksum field itself.[...] The key used > MUST be the session key in the ticket. > > 7 ISAKMP Key Derivation [....] > > o SKEYID_d is the session key in the Kerberos service ticket from > the AP-REQ. Note that subkeys are not used in KINK and MUST be > ignored if received. > > This issue has been discussed in the past (multiple times even), and > bringing it up again will probably not result in anything other than wasted > time. *nod* > I did notice that section 4.2.7 KINK_ENCRYPT does not specify what key is > used, only that it > "is encrypted using the encryption algorithm specified by the etype of the > session key" Hmmm, mumble, mumble, reflection attacks, mumble, mumble. Shouldn't KINK derive separate keys for each direction for the "cksum" and KINK_ENCRYPT payload fields? Or is there inherent protection from reflection attacks in the actual message flow? |
In reply to this post by Sam Hartman-5
On Tue, Nov 29, 2005 at 03:40:19PM -0500, Sam Hartman wrote:
> Nico, these are phase 2 IDs. I.E. they describe the SA, not the > parties involved. > > I'm afraid you are living in an IKEV2 world where terminology makes > sense. Ah, sorry. Ok, so I will assume that authorization is out of scope for KINK. Nico -- |
In reply to this post by Jeffrey Hutzelman
> 4.2.3. KINK_KRB_ERROR Payload [...]
> > KINK implementations MUST make use of a KINK Cksum field when > returning KINK_KRB_ERROR and the appropriate service key is > available. In particular, clock skew errors MUST be integrity > protected. The kerberos API, such as it is, does not guarantee that the application will have access to the ticket session key if KRB5KRB_AP_ERR_SKEW is returned from krb5_rd_req. neither mit krb5 nor heimdal return the decrypted ticket if krb5_rd_req fails. (current releases of heimdal do not check for clock skew in krb5_rd_req! This will be corrected in a future release) It does not appear that either implementation updates the keyblock stored in the auth_context until after all authenticator checks are complete, so that copy of the key is not available to the application either. While implementation concerns like this are not usually critical, in this case, I think they should be considered, since it is far more likely that this part of the spec will be ignored than the kerberos implementations be extended to make it possible for kink implementations to conform to it. I do not recommend just removing the integrity protection requirement from skew errors. if integrity for skew errors was not required, an attacker might be able to coerce an initiator into producing an AP_REQ that is invalid now, but could be successfully replayed at a later time. |
On Tue, Nov 29, 2005 at 06:01:15PM -0500, Chaskiel M Grundman wrote:
> >4.2.3. KINK_KRB_ERROR Payload [...] > > > > KINK implementations MUST make use of a KINK Cksum field when > > returning KINK_KRB_ERROR and the appropriate service key is > > available. In particular, clock skew errors MUST be integrity > > protected. > > The kerberos API, such as it is, does not guarantee that the application > will have access to the ticket session key if KRB5KRB_AP_ERR_SKEW is > returned from krb5_rd_req. neither mit krb5 nor heimdal return the > decrypted ticket if krb5_rd_req fails. (current releases of heimdal do not > check for clock skew in krb5_rd_req! This will be corrected in a future > release) It does not appear that either implementation updates the keyblock > stored in the auth_context until after all authenticator checks are > complete, so that copy of the key is not available to the application > either. There is no standard krb5 API... > While implementation concerns like this are not usually critical, in this > case, I think they should be considered, since it is far more likely that > this part of the spec will be ignored than the kerberos implementations be > extended to make it possible for kink implementations to conform to it. ...but I tend to agree. Ultimately some error notifications simply cannot be integrity protected, so initiators must be prepared to receive such notifications and deal with them, either by giving up early or retrying with a timeout. Attempting to do better than Kerberos V itself does for error messages seems likely to create API problems. The value of protecting skew error messages is this: clients can work around server-side skew when otherwise they could not. Such a feature too would require API work: krb5_rd_rep*() would need a way to output skew between the client and server, and krb5_mk_req*() would need a skew input (that would have to be used very, very carefully). Is it wise for Kerberos V applications to be doing this sort of thing? And should Kerberos V clients ever correct for skew other than that between the client and the KDC? Why can't the servers do their own KDC exchanges to discover server-side skew? (Why, for u2u they'd be engaging in such KDC exchanges anyways...) I'm convinced, I think. This feature should be removed. Nico -- |
In reply to this post by Nicolas Williams
At Tue, 29 Nov 2005 15:39:04 -0600,
Nicolas Williams <[hidden email]> wrote: > > > I did notice that section 4.2.7 KINK_ENCRYPT does not specify what key is > > used, only that it > > "is encrypted using the encryption algorithm specified by the etype of the > > session key" > > Hmmm, mumble, mumble, reflection attacks, mumble, mumble. > > Shouldn't KINK derive separate keys for each direction for the "cksum" > and KINK_ENCRYPT payload fields? Or is there inherent protection from > reflection attacks in the actual message flow? The KINK_ENCRYPT payload is tied with AP-REQ (or AP-REP) with the Cksum field. I thought it is enough to prevent reflection. Isn't it? -- KAMADA Ken'ichi <[hidden email]> |
In reply to this post by Nicolas Williams
At Tue, 29 Nov 2005 17:31:37 -0600,
Nicolas Williams <[hidden email]> wrote: > > > While implementation concerns like this are not usually critical, in this > > case, I think they should be considered, since it is far more likely that > > this part of the spec will be ignored than the kerberos implementations be > > extended to make it possible for kink implementations to conform to it. > > ...but I tend to agree. > > Ultimately some error notifications simply cannot be integrity > protected, so initiators must be prepared to receive such notifications > and deal with them, either by giving up early or retrying with a > timeout. Attempting to do better than Kerberos V itself does for error > messages seems likely to create API problems. > > The value of protecting skew error messages is this: clients can work > around server-side skew when otherwise they could not. > > Such a feature too would require API work: krb5_rd_rep*() would need a > way to output skew between the client and server, and krb5_mk_req*() > would need a skew input (that would have to be used very, very > carefully). > > Is it wise for Kerberos V applications to be doing this sort of thing? When I was implementing this part of the spec using MIT krb5 and Heimdal (when I was not yet involved with editing the draft), it was much of a bother, though not impossible with accessing the library internals. The code is included in ftp://ftp.kame.net/pub/racoon2/racoon2-20051102a.tgz, but is very dirty, over-familiar with the library, and fragile with library upgrades. On the other hand, rfc1510ter will have checksummed KRB-ERROR. Doesn't that mean we need API work anyway when rfc1510ter is standardized, in order to extract key on the failure of krb5_rd_req()? -- KAMADA Ken'ichi <[hidden email]> |
In reply to this post by Nicolas Williams
On Tue, Nov 29, 2005 at 03:39:04PM -0600, Nicolas Williams wrote:
> On Tue, Nov 29, 2005 at 03:57:40PM -0500, Chaskiel M Grundman wrote: > > I did notice that section 4.2.7 KINK_ENCRYPT does not specify what key is > > used, only that it > > "is encrypted using the encryption algorithm specified by the etype of the > > session key" > > Hmmm, mumble, mumble, reflection attacks, mumble, mumble. > > Shouldn't KINK derive separate keys for each direction for the "cksum" > and KINK_ENCRYPT payload fields? Or is there inherent protection from > reflection attacks in the actual message flow? Well, I also note stuff like: "[The XID] is not used for replay protection because that functionality is provided by Kerberos." But KINK isn't using KRB-SAFE or KRB-PRIV, it's using raw KCRYPTO! So the only place that KINK gets replay protection for free from Kerberos V is in the AP exchange. So, how exactly does KINK get "replay protection of key management messages," a goal stated in the first paragraph of the introduction? Did I miss something? Another problem is that there seems to be no way of tying a particular KINK message, making use of a Kerberos V key, to a given AP exchange/ Ticket. This might be fine for a KE that follows the IKEv1/RFC2401 model, but it seems to me that it isn't fine in an IKEv2/RFC2401bis world. Nico -- |
In reply to this post by KAMADA Ken'ichi
>>>>> "KAMADA" == KAMADA Ken'ichi <[hidden email]> writes:
KAMADA> The KINK_ENCRYPT payload is tied with AP-REQ (or AP-REP) KAMADA> with the Cksum field. I thought it is enough to prevent KAMADA> reflection. Isn't it? I believe so. |
In reply to this post by Nicolas Williams
On Wed, Nov 30, 2005 at 11:07:35AM -0600, Nicolas Williams wrote:
> So the only place that KINK gets replay protection for free from > Kerberos V is in the AP exchange. So, how exactly does KINK get "replay > protection of key management messages," a goal stated in the first > paragraph of the introduction? Did I miss something? Yes, I missed something: every KINK message has an AP-REQ or AP-REP (or KRB-ERROR). The KINK "checksum" field and KINK_ENCRYPT payload use keys derived from the session key of the Ticket, which would normally mean that Ticket reuse implies key reuse which brings replay protection into question. But the presence of an AP-REQ or AP-REP in the KINK message that is part of the checksum input means that key reuse is not enough to lead to replays, and the presence of timestamps in the Authenticator and AP-REP enc part means that the inputs to the checksum cannot be replayed unless time goes backwards, and the requirement that the AP-REP timestamps match the AP-REQ timestamps provides replay protection to the client. This also answers my question about reflection attacks. Is this analysis correct? Nico -- |
In reply to this post by Sam Hartman-5
On Wed, Nov 30, 2005 at 12:24:13PM -0500, Sam Hartman wrote:
> >>>>> "KAMADA" == KAMADA Ken'ichi <[hidden email]> writes: > > > KAMADA> The KINK_ENCRYPT payload is tied with AP-REQ (or AP-REP) > KAMADA> with the Cksum field. I thought it is enough to prevent > KAMADA> reflection. Isn't it? > > I believe so. Yes, I had not noticed that all KINK messages have an AP-REQ, AP-REP or KRB-ERROR. Nico -- |
In reply to this post by Nicolas Williams
Nicolas Williams wrote:
> On Wed, Nov 30, 2005 at 11:07:35AM -0600, Nicolas Williams wrote: > >>So the only place that KINK gets replay protection for free from >>Kerberos V is in the AP exchange. So, how exactly does KINK get "replay >>protection of key management messages," a goal stated in the first >>paragraph of the introduction? Did I miss something? > > > Yes, I missed something: every KINK message has an AP-REQ or AP-REP (or > KRB-ERROR). > > The KINK "checksum" field and KINK_ENCRYPT payload use keys derived from > the session key of the Ticket, which would normally mean that Ticket > reuse implies key reuse which brings replay protection into question. > But the presence of an AP-REQ or AP-REP in the KINK message that is part > of the checksum input means that key reuse is not enough to lead to > replays, and the presence of timestamps in the Authenticator and AP-REP > enc part means that the inputs to the checksum cannot be replayed unless > time goes backwards, and the requirement that the AP-REP timestamps > match the AP-REQ timestamps provides replay protection to the client. > > This also answers my question about reflection attacks. > > Is this analysis correct? That's pretty much how I remember it. Mike |
In reply to this post by Nicolas Williams
Thank you for your review.
At Tue, 29 Nov 2005 12:41:38 -0600, Nicolas Williams <[hidden email]> wrote: > > - Rekeying > > " > 3.6. Rekeying Security Associations > > KINK requires the initiator of an SA to be responsible for rekeying > the SA. ... > " > > First, "requires" isn't proper RFC2119 terminology, and proper > RFC2119 terminology in this regard is missing in that section. This > would be fine, except that... > > ...second, since KINK allows for user-to-user Kerberos V exchanges I > see no reason that responders couldn't, if they wanted to, act as > initiators, so there's a question, I think, as to whether responders > are simply not allowed to do that or merely expected to not do that. > Or did I miss something else? A responder can become an initiator (with U2U if necessary) and it's possible to rekey from the responder, but it is not expected in my opinion. KINK could disallow the responder to rekey, but still, the responder can make new SAs (pretending independent of rekeying) and delete old ones, and it cannot be distinguished from rekeying from the initiator. So I don't think "disallowing" and "expecting-not-to-do" have much difference in this case. > Third, even if responders typically could not act as initiators (say, > for implementation-specific issues), one might still want some > notification that an SA has expired and traffic needs it to be > rekeyed. KINK is based on IKE(v1) and negotiates SA lifetime (see the first paragraph of section 3.2 of kink-10), so the initiator should notice SA expiration and rekey it. > - Section 5.3 limits the IDs that can be used with KINK to > address/subnet/address range IDs. I think this is too limited, it > seems likely to make KINK very difficult to use. > > I'd rather that a new ID type be defined that corresponds to Kerberos > V principal names and/or that ID_FQDN and ID_RFC822_ADDR be allowed > and a simple algorithm be recommended for matching principals and > such IDs. Section 5.3 says that IDs in KINK identify traffic to be protected (like TSs in IKEv2). Peer's identifiers are pricnipal names provided in AP exchange. (Note that AP_REQ and AP_REP are always exchanged when negotiating SAs.) > - Section 4.2.4. How does cross-realm user-to-user work? > > Also, this doesn't make sense: > > " > ... When the requested principal is > "principal@REALM", ... > " > > Isn't "principal@REALM" pretty much the only form that the requested > principal name can take? Or are there other forms? Where are those > described? That paragraph is poorly worded, sorry. The string "principal" and "REALM" in the quoted sentence correspond to the same strings in that sentence. So, what I wanted to say was: - The returned TGT MUST be a non-inter-realm TGT of the requested realm, and - The cname/crealm of the TGT MUST match the requested principal. I'd propose to change the paragraph with this one: o PrincName -- The name of the principal which the initiator want to communicate with. It is assumed that the initiator knows the responder's principal name (including the realm name) in the same way as the non-User-to-User case. The returned TGT MUST NOT be an inter-realm TGT and it's cname and crealm MUST match the requested principal name, so that the initiator can rendezvous with the responder at the responder's realm. For comparison, here is the old one: o PrincName -- The name of the principal which the initiator want to communicate with. It is assumed that the initiator knows the responder's principal name (including the realm name) in the same way as the non-User-to-User case. When the requested principal is "principal@REALM", the responder MUST return a ticket whose server and client principals are "krbtgt/REALM@REALM" and "principal@REALM" respectively, so that the initiator can obtain a User-to-User service ticket at the KDC of the responder's realm. > - Section 4.2.4. How are the values of PrincName constructed? Are > they DER encodings of > > SEQUENCE { pname PrincipalName, realm, RealmName}? > > Or are they an "unparsed" representation of principal names following > rules similar to those listed in RFC4121? > > This is very simply dealt with by saying that the contents of > PrincName is given by section 2.1.3 of RFC1964, but without the > GSS-API exported name token header. I don't have noticed it wasn't defined. Thank you for pointing it out. I assumed "unparsed" representation, so your deal sounds good to me. -- KAMADA Ken'ichi <[hidden email]> |
On Thu, Dec 01, 2005 at 01:14:31PM +0900, KAMADA Ken'ichi wrote:
> Thank you for your review. And you for your reply. > At Tue, 29 Nov 2005 12:41:38 -0600, > Nicolas Williams <[hidden email]> wrote: > > > > - Rekeying > > > > " > > 3.6. Rekeying Security Associations > > > > KINK requires the initiator of an SA to be responsible for rekeying > > the SA. ... > > " > > > > First, "requires" isn't proper RFC2119 terminology, and proper > > RFC2119 terminology in this regard is missing in that section. This > > would be fine, except that... > > > > ...second, since KINK allows for user-to-user Kerberos V exchanges I > > see no reason that responders couldn't, if they wanted to, act as > > initiators, so there's a question, I think, as to whether responders > > are simply not allowed to do that or merely expected to not do that. > > Or did I miss something else? > > A responder can become an initiator (with U2U if necessary) and it's > possible to rekey from the responder, but it is not expected in my > opinion. > > KINK could disallow the responder to rekey, but still, the responder > can make new SAs (pretending independent of rekeying) and delete old > ones, and it cannot be distinguished from rekeying from the initiator. > So I don't think "disallowing" and "expecting-not-to-do" have much > difference in this case. Allow me to re-phrase: is the "requires" above intended to have the force of "REQUIRED"? If not, might it be better to replace it with "expects"? "KINK expects the initiator of an SA to be responsible for rekeying..." would not have confused me... :) > > Third, even if responders typically could not act as initiators (say, > > for implementation-specific issues), one might still want some > > notification that an SA has expired and traffic needs it to be > > rekeyed. > > KINK is based on IKE(v1) and negotiates SA lifetime (see the first > paragraph of section 3.2 of kink-10), so the initiator should notice > SA expiration and rekey it. Are initiators REQUIRED to rekey expired SAs, even when no outgoing packets require them? If not, how could the initiator know that there are no packets on the server side in need of a rekeyed SA? > > - Section 4.2.4. How does cross-realm user-to-user work? > > > > Also, this doesn't make sense: > > > > " > > ... When the requested principal is > > "principal@REALM", ... > > " > > > > Isn't "principal@REALM" pretty much the only form that the requested > > principal name can take? Or are there other forms? Where are those > > described? > > That paragraph is poorly worded, sorry. The string "principal" and > "REALM" in the quoted sentence correspond to the same strings in that > sentence. So, what I wanted to say was: > - The returned TGT MUST be a non-inter-realm TGT of the requested > realm, and > - The cname/crealm of the TGT MUST match the requested principal. Right. > I'd propose to change the paragraph with this one: > > o PrincName -- The name of the principal which the initiator want to > communicate with. It is assumed that the initiator knows the > responder's principal name (including the realm name) in the same > way as the non-User-to-User case. The returned TGT MUST NOT be an > inter-realm TGT and it's cname and crealm MUST match the requested > principal name, so that the initiator can rendezvous with the > responder at the responder's realm. Yes, I like this. > > - Section 4.2.4. How are the values of PrincName constructed? Are > > they DER encodings of > > > > SEQUENCE { pname PrincipalName, realm, RealmName}? > > > > Or are they an "unparsed" representation of principal names following > > rules similar to those listed in RFC4121? > > > > This is very simply dealt with by saying that the contents of > > PrincName is given by section 2.1.3 of RFC1964, but without the > > GSS-API exported name token header. > > I don't have noticed it wasn't defined. Thank you for pointing it > out. I assumed "unparsed" representation, so your deal sounds good > to me. Ok, so add text like this to your text above: PrincName values are octet string representations of a principal and realm name formatted just like the to the octet string used in the "NAME" component of GSS-API [RFC2743] exported name token for the Kerberos V GSS-API mechanism [RFC1964]. See RFC1964, section 2.1.3. You'll have to add a normative reference to RFC1964. And you'll have to add an informative reference to RFC2743 (informative because the text in RFC1964 is sufficient to implement figure out how to encode PrincName). Nico -- |
In reply to this post by KAMADA Ken'ichi
On Thu, Dec 01, 2005 at 01:14:31PM +0900, KAMADA Ken'ichi wrote:
> At Tue, 29 Nov 2005 12:41:38 -0600, > Nicolas Williams <[hidden email]> wrote: > > - Section 5.3 limits the IDs that can be used with KINK to > > address/subnet/address range IDs. I think this is too limited, it > > seems likely to make KINK very difficult to use. > > > > I'd rather that a new ID type be defined that corresponds to Kerberos > > V principal names and/or that ID_FQDN and ID_RFC822_ADDR be allowed > > and a simple algorithm be recommended for matching principals and > > such IDs. > > Section 5.3 says that IDs in KINK identify traffic to be protected > (like TSs in IKEv2). Peer's identifiers are pricnipal names provided > in AP exchange. (Note that AP_REQ and AP_REP are always exchanged > when negotiating SAs.) Right, I was confused -- Sam explained how I got confused. It would be nice if KINK supported IKEv2-style traffic selectors, but I assume that's out of scope here. Nico -- |
Free forum by Nabble | Edit this page |