Subject: [Ietf-krb-wg] padata # collision in kerberos OTP support

From: Larry Zhu <[email-masked]>
Date: Mon, 2 Mar 2009 08:35:04 -0800

It has been reported and confirmed that draft-ietf-krb-wg-otp-preauth-09.txt makes use of existing pdata #s. These "reused" pdata #s are deployed and cannot be changed. This was the result of a process error. It seems to be the least disruptive option to reallocate the padata #s for the OTP support.

The new #s are as shown in the table below. Please let us know if you have any concerns.

      Type                Value    Reference
  ----------------------------------------------------------------------
  PA-TGS-REQ                 1    RFC 4120
  PA-ENC-TIMESTAMP           2    RFC 4120
  PA-PW-SALT                 3    RFC 4120
  [reserved]                 4
  PA-ENC-UNIX-TIME           5    (deprecated)
  PA-SANDIA-SECUREID         6
  PA-SESAME                  7
  PA-OSF-DCE                 8
  PA-CYBERSAFE-SECUREID      9
  PA-AFS3-SALT               10
  PA-ETYPE-INFO              11   RFC 4120
  PA-SAM-CHALLENGE           12   (sam/otp)
  PA-SAM-RESPONSE            13   (sam/otp)
  PA-PK-AS-REQ_OLD           14   draft-ietf-cat-kerberos-pk-init-09
  PA-PK-AS-REP_OLD           15   draft-ietf-cat-kerberos-pk-init-09
  PA-PK-AS-REQ               16   RFC 4556
  PA-PK-AS-REP               17   RFC 4556
  PA-ETYPE-INFO2             19   RFC 4120
  PA-USE-SPECIFIED-KVNO      20
  PA-SAM-REDIRECT            21   (sam/otp)
  PA-GET-FROM-TYPED-DATA     22   (embedded in typed data)
  TD-PADATA                  22   (embeds padata)
  PA-SAM-ETYPE-INFO          23   (sam/otp)
  PA-ALT-PRINC               24   ([email-masked])
  PA-SAM-CHALLENGE2          30   ([email-masked])
  PA-SAM-RESPONSE2           31   ([email-masked])
  PA-EXTRA-TGT               41   Reserved extra TGT
  TD-PKINIT-CMS-CERTIFICATES 101  CertificateSet from CMS
  TD-KRB-PRINCIPAL           102  PrincipalName
  TD-KRB-REALM               103  Realm
  TD-TRUSTED-CERTIFIERS      104  from PKINIT
  TD-CERTIFICATE-INDEX       105  from PKINIT
  TD-APP-DEFINED-ERROR       106  application specific
  TD-REQ-NONCE               107  INTEGER
  TD-REQ-SEQ                 108  INTEGER
  PA-PAC-REQUEST             128  MS-KILE
  PA-FOR_USER                129  MS-KILE
  PA-FOR-X509-USER           130  MS-KILE
  PA-FOR-CHECK_DUPS          131  MS-KILE
  PA-AS-CHECKSUM             132  MS-KILE
  PA-OTP-CHALLENGE           141  ([email-masked])
  PA-OTP-REQUEST             142  ([email-masked])
  PA-OTP-CONFIRM             143  ([email-masked])
  PA-SUPPORTED-ETYPES        165  MS-KILE

In addition, for consistency with RFC4120, it is recommended that the OTP draft uses "-" instead of "_" in the symbolic names of its allocated padata numbers, also illustrated in the table above.

--Larry

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: <[email-masked]>
Date: Tue, 3 Mar 2009 05:20:32 -0500

Larry,

I will update the padata numbers as listed below and check in an update.

The  ID draft-ietf-krb-wg-otp-preauth-09.txt also has a
PA-OTP-PIN_CHANGE, is it OK if I go ahead and use 134 for that?

PA-OTP-CHALLENGE           141  ([email-masked])
PA-OTP-REQUEST             142  ([email-masked])
PA-OTP-CONFIRM             143  ([email-masked])
PA-OTP-PIN-CHANGE          144  ([email-masked])

I modelled the use of "_" and "-" on the system used in the pre-auth
framework ID "_" are used for the padata symbolic name and "-" are used
for the corresponding ASN.1 type.  To be consistent with RFC4120, I will
change over to "-" but from what I have seen, there does not seem to be
a convention in the naming of the two types.

--Gareth

> -----Original Message-----
> From: Larry Zhu [mailto:[email-masked]] 
> Sent: 02 March 2009 16:35
> To: [email-masked]
> Cc: Richards, Gareth
> Subject: padata # collision in kerberos OTP support
> 
> It has been reported and confirmed that 
> draft-ietf-krb-wg-otp-preauth-09.txt makes use of existing 
> pdata #s. These "reused" pdata #s are deployed and cannot be 
> changed. This was the result of a process error. It seems to 
> be the least disruptive option to reallocate the padata #s 
> for the OTP support.
> 
> In addition, for consistency with RFC4120, it is recommended 
> that the OTP draft uses "-" instead of "_" in the symbolic 
> names of its allocated padata numbers, also illustrated in 
> the table above.
> 
> --Larry
> 
> 
>

---

From: Larry Zhu <[email-masked]>
Date: Tue, 24 Mar 2009 12:18:52 -0700

Sorry I missed that. Can you use 144 for PA-OTP-PIN-CHANGE?

134 is already used by draft-ietf-krb-wg-otp-preauth.

--Larry

p.s. I took the liberty to change the symbolic name to use "-" before the "CHANGE", please shout if the original usage was intentional :-).
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, March 03, 2009 2:21 AM
To: Larry Zhu; [email-masked]
Subject: Re: [Ietf-krb-wg] padata # collision in kerberos OTP support

Larry,

--Gareth

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 24 Mar 2009 14:17:10 -0700

> 134 is already used by draft-ietf-krb-wg-otp-preauth.

Huh?  We're _talking_ about draft-ietf-krb-wg-otp-preauth.
What other thing already uses 134?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Larry Zhu <[email-masked]>
Date: Tue, 24 Mar 2009 14:25:59 -0700

134 is used by FAST.

PA-AUTHENTICATION-SET      134  draft-ietf-krb-wg-preauth-framework

---

From: <[email-masked]>
Date: Wed, 25 Mar 2009 08:14:17 -0400

Larry,

It looks as if my original email was a bit garbled.   I meant, is it OK
if I go ahead and use 144 for PA-OTP-PIN-CHANGE?
I have made the change in the current working document.

--Gareth 

> Sent: 24 March 2009 15:19
> To: Richards, Gareth; [email-masked]
> Subject: RE: padata # collision in kerberos OTP support
> 
> p.s. I took the liberty to change the symbolic name to use 
> "-" before the "CHANGE", please shout if the original usage 
> was intentional :-).
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> I modelled the use of "_" and "-" on the system used in the 
> pre-auth framework ID "_" are used for the padata symbolic 
> name and "-" are used for the corresponding ASN.1 type.  To 
> be consistent with RFC4120, I will change over to "-" but 
> from what I have seen, there does not seem to be a convention 
> in the naming of the two types.
> 
> --Gareth
> 
> 
> pdata #s. 
> > These "reused" pdata #s are deployed and cannot be changed. 
> This was 
> > the result of a process error. It seems to be the least disruptive 
> > option to reallocate the padata #s for the OTP support.
> >
> > The new #s are as shown in the table below. Please let us 
> know if you 
> > have any concerns.
> >
> >       Type                Value    Reference
> >
> > 
> > In addition, for consistency with RFC4120, it is 
> recommended that the 
> > OTP draft uses "-" instead of "_" in the symbolic names of its 
> > allocated padata numbers, also illustrated in the table above.
> >
> > --Larry
> >
> >
> >

---

From: "Thomas Hardjono" <[email-masked]>
Date: Wed, 25 Mar 2009 11:33:32 -0500

I noticed that the PKCROSS draft has expired a few years ago:
http://tools.ietf.org/html/draft-ietf-cat-kerberos-pk-cross-08

I was wondering if anyone would be interested in resurrecting it and
completing the draft.

Thoughts?

cheers,

/thomas.

---

From: Shoichi Sakane <[email-masked]>
Date: Wed, 25 Mar 2009 11:14:12 -0700

Hi,

I really wanted to resurrect it for reducing a client burden during cross-realm
operation.  Before that, we needed other staff like ticket extensions.  however,
Love's draft is becoming mature.  So, we might restart.

See attached mail for your more information.  I asked some of the authors,
and they won't have time to move it forward anymore.

===
Shoichi Sakane

> I was wondering if anyone would be interested in resurrecting it and

Subject: cross-realm issues (Re: Charter discussion)
From: Shoichi Sakane <[email-masked]>
To: [email-masked]
Date: Mon, 12 Mar 2007 20:31:23 +0900

Hi Jeff and all,

Jeffrey Hutzelman wrote:
> It is time to resume our charter discussion.  Based on discussions with
> Sam and comments received at the last meeting, I've refined my charter
> update proposal; the latest version can be found at the end of this
> message.  The primary open issues are these:

> (4) Do we want to adopt a work item to examine cross-realm issues?

> * Examine issues related to the current cross-realm model, produce a
>  list of problems to be solved, and evaluate approaches to solving them.

Please let me summarize the work so far related to the item #4,
cross-realm issues, and please let me talk about my opinion.

As the first step, I wrote a document that lists cross-realm issues
and defines the problems, which is probably included well-known problems.
The current draft is draft-sakane-krb-cross-problem-statement-01.txt.
I think that this document includes most of problems related to not
only specific area, but also typical network environment though the
title of the document uses "specific environtment".  If those things
are not enough to move our process forward, I need more input in order
to find out the other issues and problems.  Then we can evaluate
approaches.

As our next step, it is maybe too early to consider, Ken'ichi and I
have proposed a model to solve most of problems that described in the
problem statement document.
The current draft is draft-kamada-krb-client-friendly-cross-01.txt.
I announced my previous mail.  This document proposes a model
constructed by two modes.

Third, PK-CROSS will become obviously one of approaches to solve problems.
The second proposed document also mentions the mechanism.  I would like
to put this mechanism on the table again though I am not sure whether the
authors are focusing it still.  I will ask them.  If they don't have time,
I am ready to be editor or something like that.  I would like to have
any comment about my thought please.

Finally, Saber and others, including me, are proposing another approach
to solve cross-realm problem.
The current draft is draft-zrelli-krb-xtgsp-01.txt.
This approach is lettle different from the model that I proposed in previous
document.  However, this approach has an advantage, this is also mentioned
at the second proposed document.  We also have to evaluate it.

These are current status related to cross-realm work which I know.
IMHO, if there are some people interested in the item, we probably need
a small meeting at Prague.  I will send a request on another mail.

In summarize, we have four documents so far.
1. draft-sakane-krb-cross-problem-statement-01.txt.
2. draft-kamada-krb-client-friendly-cross-01.txt.
3. draft-ietf-cat-kerberos-pk-cross-08.txt (expired)
4. draft-zrelli-krb-xtgsp-01.txt.

Any comments and information are welcome.

Regards,