[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [secdir] Please review draft-ietf-capwap-protocol-specification's use of certificates
I've been sending these emails to the Cable Labs folks with the
intention of getting them involved. I'm thinking that this is a great
opportunity to improve interoperability especially between different
domains. It is also maybe an opportunity to reduce the number of
purpose specific certs that are used in Cable Modems as has been a
stated goal by Cable Labs.
We can see that the DOCSIS standards are having impact outside of their
specific domain of cable modem interoperability. As I've stated before,
we are using a similar model in other types of electronics products, and
I know of other manufacturers headed in the same direction.
The DOCSIS 3.0 standards could still be changed I believe. This could
be a path to righting some wrongs if they are really wrong. I'm not
sure they are wrong, but I do know that we are going to be moving down
this path of CN=MAC for even more products very soon.
Speaking for myself and the certs that I create under DOCSIS (+10M/yr),
it would not be a difficult change. However, there are a lot of other
components that would be affected. Again, the DOCSIS 3.0 effort would
go a long way in providing cover for such a change.
I'm not for or against such a change, but I do think that there is a
fleeting opportunity if change is needed.
Thanks
Ron Ogle
Thomson Product Security
> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Scott G. Kelly
> Sent: Monday, January 07, 2008 1:42 PM
> To: Joseph Salowey (jsalowey); Stephen Kent; Sam Hartman
> Cc: capwap-chairs@xxxxxxxxxxxxxx; ietf-pkix@xxxxxxx; secdir@xxxxxxx
> Subject: RE: [secdir] Please review
> draft-ietf-capwap-protocol-specification's use of certificates
>
>
> Hi Joe,
>
> jsalowey wrote:
> >It seems that stating that the identifier used in a
> certificate MUST be
> >a MAC address may be overly restrictive. It seems you would want to
> >allow for MAC address, but not require it. Is there a reason why the
> >identifier needs to be a MAC address (if I understand
> correctly the AC
> >and WTP may not be directly L2 connected and may not have direct
> >knowledge of each others MAC address)?
> >
> >Why wouldn't another identifier string be acceptable?
> >
> >Is the MAC address interpreted by the peer or is it just an
> identifier
> >string?
> >
> >If there are multiple MAC addresses which one is used?
>
> These are all good questions. The MAC was originally chosen
> for two reasons:
>
> 1) in the initial LWAPP design, devices were always directly
> connected (it was a L2 protocol which was later extended to
> include L3 support)
>
> 2) at the time, this was the convention for
> DOCSIS/PacketCable, and the guy who suggested that it be
> included in LWAPP device certs (me) didn't know there was
> anything incorrect about this approach.
>
> Since MAC addresses are not typically assigned to more than
> one device, it seems like a reasonable choice for a
> vendor-independent approach to network device identification.
> Still, as you point out, many devices have more than one MAC
> address, and this raises the question of, which one?
>
> In any event, there are a *lot* of legacy devices out there
> that follow this convention today, and that was the rationale
> for my introduction of the term "pragmatic" in my reply to Steve.
>
> I wasn't suggesting that we introduce a hack to cut corners,
> and if I had to say over again, my comments would be more in
> line with Bernard's follow up post, i.e. there are lots of
> devices out there that already do this, and it is not very
> practical (pragmatic?) to define a standard that will not be
> backwardly compatible with these devices.
>
> I think it's really important to understand 2 things with
> respect to legacy devices employing this convention: first,
> they typically inject certs during manufacturing, and
> changing this will be, in many cases, non-trivial. There are
> PKI vendors (e.g. Verisign) which provide manufacturing
> services supporting this convention, so such changes would
> have potentially far-reaching implications. Second, replacing
> the already-deployed certs is a non-starter for most vendors.
> Hence, we need a solution which somehow accommodates this convention.
>
> I'm not sure what the best solution is going forward. I agree
> that the Serial Number attribute is more appropriate than CN,
> but I think we have to accommodate deployed devices. Do we
> change the convention now, but still permit the MAC-as-CN, or
> do we simply continue to use the MAC-as-CN?
>
> I think it's reasonable to discuss what you've suggested
> above, i.e. accept the MAC in the CN, but recommend something
> different (don't make CN=MAC a MUST).
>
> Scott
>
> >Joe
> >
> >> -----Original Message-----
> >> From: secdir-bounces@xxxxxxx [mailto:secdir-bounces@xxxxxxx]
> >> On Behalf Of Scott G. Kelly
> >> Sent: Friday, December 21, 2007 1:55 PM
> >> To: Stephen Kent; Sam Hartman
> >> Cc: capwap-chairs@xxxxxxxxxxxxxx; ietf-pkix@xxxxxxx; secdir@xxxxxxx
> >> Subject: Re: [secdir] Please review
> >> draft-ietf-capwap-protocol-specification's use of certificates
> >>
> >> Hi Steve,
> >>
> >> Thanks for taking a look at this. Regarding placement of the
> >> MAC in the CN, I would offer two observations:
> >>
> >> 1) this is what is specified in the DOCSIS and PacketCable
> >> cert profiles, and it was on this basis that device certs for
> >> LWAPP were originally designed in this way. You can see the
> >> DOCSIS profile at www.drizzle.com/~aboba/CPW/DOCSIS.ppt
> >>
> >> 2) I don't see anything in the X.520 language that explicitly
> >> precludes this usage, so assuming that the docsis/packetcable
> >> designers reviewed that spec, I can see how they could
> >> reasonably conclude that this is acceptable. Arguably, the
> >> string representation of the MAC address is "a string chosen
> >> [by the] organization responsible for the object it describes
> >> for devices and application entities".
> >>
> >> Please don't misunderstand: I'm not trying to be difficult,
> >> and I have a very healthy respect for the depth of your
> >> knowledge in this area. However, there are a *lot* of devices
> >> deployed that already use this convention. It might be more
> >> pragmatic to interpret X.520 a little less restrictively.
> >>
> >> Scott
> >>
> >> -----Original Message-----
> >> >From: Stephen Kent <kent@xxxxxxx>
> >> >Sent: Dec 21, 2007 3:00 PM
> >> >To: Sam Hartman <hartmans-ietf@xxxxxxx>
> >> >Cc: capwap-chairs@xxxxxxxxxxxxxx, ietf-pkix@xxxxxxx,
> secdir@xxxxxxx
> >> >Subject: Re: [secdir] Please review
> >> >draft-ietf-capwap-protocol-specification's use of certificates
> >> >
> >> >At 9:23 PM -0500 12/20/07, Sam Hartman wrote:
> >> >>Hi, folks. The capwap working group is preparing to last
> >> call their
> >> >>protocol specification draft.
> >> >>
> >> >>I'd appreciate review from the pkix community of section
> 2.4.4.3 and
> >> >>12.6 of this draft. These sections specify certificate
> >> validation and
> >> >>certificate usage for the protocol. Scott Kelly and
> Charles Clancy
> >> >>are security advisors for the working group and have
> been heavily
> >> >>involved.
> >> >>
> >> >>The capwap certificate profile assumes that the CN in the
> >> certificate
> >> >>has structure and contains an ethernet MAC address. The capwap
> >> >>certificate profile also assumes that parts of the subject
> >> name such
> >> >>as the organization and organizational unit will be important to
> >> >>certificate matching.
> >> >>
> >> >>I'd appreciate review and comments.
> >> >>
> >> >>--Sam
> >> >
> >> >It would be preferable to get an allocated name space for MAC
> >> >addresses, under the OtherName or, better yet, under registeredID.
> >> >
> >> >I'd argue that it is inappropriate to put a MAC address
> into a CN.
> >> >The text from X.520 makes this clear:
> >> >
> >> >The Common Name attribute type specifies an identifier of
> an object.
> >> >A Common Name is not a directory name; it is a (possibly
> ambiguous)
> >> >name by which the object is commonly known in some limited
> >> scope (such
> >> >as an organization) and conforms to the naming conventions of the
> >> >country or culture with which it is associated.
> >> >
> >> >An attribute value for common name is a string chosen
> either by the
> >> >person or organization it describes or the organization
> >> responsible for
> >> >the object it describes for devices and application entities. For
> >> >example, a typical name of a person in an
> English-speaking country
> >> >comprises a personal title (e.g., Mr., Ms., Rd, Professor,
> >> Sir, Lord),
> >> >a first name, middle name(s), last name, generation
> >> qualifier (if any,
> >> >e.g., Jr.) and decorations and awards (if any e.g., QC).
> >> >
> >> >Examples
> >> >CN = "Mr. Robin Lachlan McLeod BSc(Hons) CEng MIEE"
> >> >CN = "Divisional Coordination Committee"
> >> >CN = "High Speed Modem".
> >> >
> >> >If there is a very strong desire to make use of an existing
> >> attribute
> >> >in the X.502 space, the SerialNumber attribute makes more
> sense. So
> >> >long as we are talking about long, term, stable MAC
> >> addresses assigned
> >> >to devices by manufacturers, this is consistent with the
> >> semantics of
> >> >that attribute. Moreover, we have advised folks to use
> >> SerialNumber to
> >> >represent data such as employee/student IDs in the past, so
> >> one might
> >> >expect to see support for this attribute in many CAs and clients.
> >> >
> >> >Steve
> >>
> >> _______________________________________________
> >> secdir mailing list
> >> secdir@xxxxxxx
> >> https://mailman.mit.edu/mailman/listinfo/secdir
> >>
>
>